Red de salud construye sistema interno de conocimiento

Contexto

Una red de salud regional operando 12 instalaciones—tres hospitales y nueve clínicas ambulatorias—tenía un problema de gestión de conocimiento que era tanto común como consecuente. Las políticas clínicas y administrativas estaban dispersas a través de sitios de SharePoint, unidades compartidas, repositorios de PDF, y una intranet desactualizada. Cada instalación tenía versiones ligeramente diferentes de algunos documentos. Ninguna búsqueda única cubría todas las fuentes.

El impacto práctico: una enfermera tratando de confirmar una política de administración de medicamentos podría verificar la intranet, encontrar una versión desactualizada, verificar el SharePoint departamental, no encontrar nada, y eventualmente llamar a un supervisor—quien podría saber la respuesta o podría tener que buscar ellos mismos. Un coordinador de RH tratando de responder una pregunta de beneficios navegaría tres bibliotecas de documentos diferentes. Un oficial de cumplimiento preparándose para una auditoría gastaría días recopilando las versiones actuales de políticas relevantes.

La red tenía aproximadamente 14,000 documentos de políticas, guías clínicas, manuales de procedimientos, y materiales de referencia a través de todas las fuentes. El personal estimaba que gastaba un promedio de 18 minutos por búsqueda de información. Con miles de búsquedas ocurriendo diariamente a través de la red, el costo de tiempo acumulativo era sustancial. Peor aún, la dificultad de encontrar información actual contribuía a la deriva de cumplimiento—el personal confiaría en la memoria o impresiones desactualizadas en lugar de buscar la versión actual de una política.

Restricciones

Los sistemas de conocimiento de salud operan bajo restricciones que fundamentalmente dan forma a la arquitectura:

• Cumplimiento de HIPAA. Mientras que la base de conocimiento en sí no contiene datos de pacientes, la infraestructura debe ser compatible con HIPAA porque opera dentro del mismo entorno que maneja PHI. Todos los componentes necesitan cumplir con los requisitos de seguridad de la red, incluyendo servicios cubiertos por BAA únicamente.
• La precisión no es negociable. En salud, actuar sobre información de política desactualizada o incorrecta puede tener consecuencias de seguridad del paciente. El sistema debe mostrar versiones actuales y autorizadas de documentos y hacer la fuente claramente visible. Las respuestas alucinadas o inexactas son inaceptables.
• Acceso basado en roles. No todos los documentos son apropiados para todo el personal. Los protocolos clínicos, políticas de RH, comunicaciones ejecutivas y documentos financieros tienen diferentes requisitos de acceso. El sistema de conocimiento debe respetar los controles de acceso existentes.
• Consideración offline. Algunas áreas clínicas tienen conectividad de red limitada o intermitente. El sistema necesitaba ser diseñado para degradación elegante en lugar de fallo completo en situaciones de baja conectividad.

Enfoque

Estructuramos esto como un compromiso de 10 semanas en tres fases.

Fase 1: Auditoría de conocimiento y arquitectura (semanas 1-3). Catalogamos fuentes de documentos a través de las 12 instalaciones, mapeamos requisitos de control de acceso, evaluamos calidad y vigencia de documentos, y diseñamos la arquitectura del sistema. La auditoría reveló que aproximadamente el 30% de los documentos eran duplicados o versiones desactualizadas, y muchos documentos existían en múltiples ubicaciones con versionado inconsistente.

Fase 2: Desarrollo de pipeline e indexación (semanas 4-7). Construimos el pipeline de ingesta de documentos, infraestructura de procesamiento, base de datos vectorial y sistema de recuperación. Esta fase incluyó trabajo significativo en deduplicación de documentos, resolución de versiones (identificando la versión autorizada cuando existen múltiples versiones), y enriquecimiento de metadatos.

Fase 3: Desarrollo de aplicación y lanzamiento (semanas 8-10). Construimos la interfaz de búsqueda, la integramos con el sistema de single sign-on de la red, realizamos pruebas de usuario a través de múltiples roles e instalaciones, y lanzamos en un enfoque por fases comenzando con dos instalaciones piloto.

Arquitectura

Pipeline de ingesta de documentos. Los conectores extraen documentos de SharePoint, unidades compartidas, y la intranet en una base programada. Cada conector maneja el protocolo de API o sistema de archivos específico para su fuente. Los documentos nuevos y modificados se detectan a través del seguimiento de cambios (SharePoint) o monitoreo del sistema de archivos (unidades compartidas).

Servicio de procesamiento. Los documentos ingestados pasan por un pipeline de procesamiento: conversión de formato (PDF, Word, HTML a texto estandarizado), extracción de estructura (encabezados, secciones, tablas), extracción de metadatos (autor, fecha, departamento, tipo de documento, versión), y puntuación de deduplicación contra documentos existentes. Los documentos identificados como duplicados potenciales se marcan para que un gestor de conocimiento los resuelva.

Embedding e indexación. Los documentos procesados se dividen usando una estrategia específica de salud que preserva la estructura de políticas (manteniendo procedimientos, excepciones y referencias juntas en lugar de dividirlas a través de chunks). OpenAI Embeddings genera representaciones vectoriales que se almacenan en Pinecone junto con los metadatos del documento.

Capa de recuperación. El servicio de recuperación usa búsqueda híbrida—combinando similitud vectorial con coincidencia de palabras clave y filtrado de metadatos. Este enfoque maneja tanto consultas conceptuales (“¿cuál es nuestra política sobre transferencias de pacientes entre instalaciones?”) como búsquedas específicas (“política de administración de medicamentos MA-2024-031”). Los resultados se filtran por el rol del usuario solicitante y permisos de acceso a nivel de instalación.

Capa de aplicación. Una interfaz de búsqueda basada en React proporciona dos modos: búsqueda directa (escribe una pregunta, obtén documentos relevantes y pasajes resaltados) y búsqueda conversacional (haz preguntas de seguimiento para reducir resultados). Cada respuesta incluye enlaces a documentos fuente, fechas de versión e indicadores de confianza. El sistema nunca genera texto que no esté fundamentado en un documento específico.

Detalles de implementación

Resolución de versiones. Uno de los desafíos técnicos más complejos fue manejar múltiples versiones del mismo documento a través de diferentes fuentes. Construimos un sistema de resolución de versiones que identifica familias de documentos (variaciones de la misma política), determina la versión autorizada basada en señales de metadatos (fecha más reciente, repositorio designado, indicadores de aprobación), y asegura que los resultados de búsqueda devuelvan la versión actual mientras mantienen un enlace al historial de versiones.

Chunking para contenido de salud. Las estrategias estándar de chunking funcionaron pobremente en documentos de políticas porque dividían pasos de procedimiento, separaban excepciones de las reglas que modifican, y rompían tablas de referencia. Desarrollamos un enfoque de chunking consciente de estructura que respeta la jerarquía de documentos—manteniendo secciones completas, procedimientos y tablas como unidades atómicas. Esto aumentó el tamaño promedio de chunk pero mejoró significativamente la relevancia de recuperación.

Aplicación de fundamentación. El sistema está diseñado para nunca generar contenido sin fuente. Cuando los usuarios hacen preguntas en la interfaz conversacional, la respuesta se ensambla a partir de pasajes recuperados con citas explícitas. Si los documentos recuperados no contienen suficiente información para responder la pregunta, el sistema lo dice y sugiere documentos relacionados en lugar de generar una respuesta especulativa.

Implementación de control de acceso. Los permisos de acceso a nivel de documento se sincronizan desde los grupos de Active Directory de la red y permisos de SharePoint. Cuando un usuario busca, la capa de recuperación filtra resultados a documentos que están autorizados a acceder antes de clasificar. Esto sucede en tiempo de consulta, por lo que los permisos siempre están actuales—sin retraso entre un cambio de permiso y la búsqueda reflejándolo.

Resultados

Después de 90 días de despliegue a través de la red:

• El tiempo promedio de búsqueda bajó de 18 minutos a 2 minutos. Esto incluye el tiempo para formular la consulta, revisar resultados y confirmar que el documento es actual y autorizado. La mejora es más dramática para búsquedas interdepartamentales que anteriormente requerían verificar múltiples fuentes.
• Los hallazgos de auditoría de cumplimiento disminuyeron de 23 a 6 por trimestre. El personal está encontrando y siguiendo políticas actuales porque ahora es más fácil buscar que confiar en la memoria. Los seis hallazgos restantes fueron en áreas donde las políticas mismas necesitaban actualización, no donde el personal no pudo encontrarlas.
• La satisfacción del personal con acceso a información mejoró de 3.1 a 8.4 de 10. Encuestado a través de todos los roles e instalaciones después de 60 días de uso. Los mayores aumentos de satisfacción vinieron del personal clínico y nuevos empleados, quienes anteriormente encontraban el panorama de información más difícil de navegar.
• La deduplicación de documentos redujo la biblioteca efectiva en un 28%. La auditoría de conocimiento y proceso de deduplicación eliminaron 3,900 documentos duplicados o desactualizados, reduciendo la confusión y mejorando la relevancia de búsqueda.

Lecciones

La auditoría de conocimiento es el compromiso. Inicialmente alcanzamos la auditoría como un prerrequisito de dos semanas. Se expandió a tres semanas y podría haber tomado más. El estado de gestión de documentos a través de 12 instalaciones era peor de lo que alguien estimó—no por negligencia, sino porque 15 años de crecimiento orgánico habían creado un enredo en el que nadie tenía visibilidad. Abordar esto fue tan valioso como la tecnología de búsqueda en sí.

La estrategia de chunking es la palanca más grande para la calidad de recuperación. Probamos cinco enfoques diferentes de chunking. La diferencia entre el peor y el mejor fue dramática—del 62% al 91% de relevancia en nuestro conjunto de consultas de prueba. Para documentos estructurados como políticas y procedimientos, preservar la estructura del documento en chunks importa más que la optimización del tamaño de chunk.

La fundamentación es confianza. La decisión de nunca generar texto sin fuente fue cuestionada temprano (“¿no sería más útil si sintetizara?”), pero resultó crítica para la adopción. El personal clínico confía en el sistema porque pueden ver exactamente de dónde proviene cada pieza de información. En salud, esa trazabilidad no es solo buena de tener—es un requisito.

Próximos pasos

La red está expandiendo el sistema en dos direcciones: agregando materiales de referencia clínica (bases de datos de medicamentos, protocolos de tratamiento) con integración más estrecha en flujos de trabajo clínicos, y construyendo una capa de monitoreo de cumplimiento que proactivamente marca cuando el personal en departamentos específicos no ha accedido a políticas actualizadas que son relevantes para sus roles.

Seguridad y manejo de datos

El sistema completo se ejecuta dentro del entorno AWS compatible con HIPAA de la red, cubierto por el BAA de AWS. Mientras que la base de conocimiento no contiene PHI, la infraestructura cumple con los requisitos de HIPAA porque opera dentro del mismo límite de seguridad. Todos los datos están cifrados en reposo (AES-256) y en tránsito (TLS 1.2+). Los registros de acceso se retienen según el cronograma de retención de cumplimiento de la red. La API de OpenAI Embeddings se usa bajo un acuerdo empresarial con un BAA que prohíbe el uso de datos para entrenamiento de modelos. Pinecone opera dentro de la misma región de AWS con controles de seguridad equivalentes.

Este caso de estudio representa un compromiso real con detalles modificados para proteger la confidencialidad del cliente. Las métricas específicas son representativas de resultados reales.