Aprenda a modelar, buscar, navegar y contextualizar la terminología clínica SNOMED CT con MongoDB Atlas.
caso de uso: Interoperabilidad
Industrias: Salud
Productos: MongoDB Atlas, MongoDB Search, MongoDB Vector Search, Voyage AI
Descripción general de la solución
Las aplicaciones sanitarias necesitan comprender el significado clínico, no solo almacenar texto clínico. Un médico puede escribir «insuficiencia cardíaca», «fallo cardíaco» o «insuficiencia cardíaca». Diferentes palabras pueden describir la misma idea clínica. La codificación clínica proporciona a las aplicaciones una forma estandarizada de representar ese significado con identificadores estables.
Los equipos sanitarios utilizan distintos sistemas de codificación para diferentes fines. Algunos sistemas agrupan diagnósticos y consultas para la elaboración de informes, estadísticas, reembolsos o análisis de la actividad hospitalaria. SNOMED CT se centra en el significado clínico dentro del historial clínico. Puede representar problemas, hallazgos, procedimientos, estructuras corporales, organismos, sustancias, productos y muchos otros conceptos clínicos. SNOMED CT admite aplicaciones para buscar, intercambiar, analizar o razonar sobre los datos clínicos registrados en un historial clínico electrónico.
SNOMED International describe SNOMED CT como una terminología clínica con conceptos que tienen significados únicos, definiciones formales y una organización jerárquica.
SNOMED CT tiene una estructura gráfica. Existen más de 500,000 conceptos clínicos, cada uno de los cuales puede tener varias descripciones legibles para humanos, incluyendo sinónimos y traducciones. Puede tener conceptos padre, conceptos hijo, ancestros y relaciones formales con otros conceptos. SNOMED CT representa el contenido terminológico mediante conceptos, descripciones y relaciones de la siguiente manera:
Un concepto representa una idea clínica.
Una descripción vincula un término legible para el ser humano con ese concepto.
Una relación conecta un concepto con otro.
Esta estructura es potente, pero plantea desafíos de implementación. Los equipos de desarrollo de aplicaciones necesitan búsqueda rápida de términos, búsqueda multilingüe, navegación jerárquica, expansión de descendientes e inspección de relaciones. También necesitan utilizar la terminología de SNOMED en flujos de trabajo como la revisión de notas clínicas, la creación de listas de problemas, el apoyo a la toma de decisiones, la identificación de cohortes y la búsqueda semántica. Las implementaciones tradicionales suelen dividir estas necesidades entre varios sistemas.
Una base de datos relacional para los archivos de terminología.
Un motor de búsqueda para la consulta de texto.
Una base de datos gráfica para el recorrido de jerarquías.
Una base de datos vectorial para búsqueda semántica.
Esta solución muestra cómo poner en funcionamiento SNOMED CT en MongoDB Atlas de la siguiente manera:
Almacene cada concepto SNOMED como un documento de MongoDB que mantenga juntos la identidad del concepto, las descripciones, las relaciones, los padres, los hijos y las rutas ancestrales.
Cree una proyección de búsqueda a nivel de término para MongoDB Search y MongoDB Vector Search.
Utilice matrices de ancestros e índices de claves múltiples para admitir jerarquías comunes y consultas de descendientes sin necesidad de una base de datos de grafos independiente.
Utilice el mismo servicio de terminología para vincular las notas clínicas con los candidatos de SNOMED.
Almacena las codificaciones revisadas con evidencia, contexto y rutas ancestrales.
Por ejemplo, un usuario puede buscar "insuficiencia cardíaca", inspeccionar el concepto clínico seleccionado, ver sus conceptos padre e hijo, revisar sus relaciones formales y expandir conceptos específicos debajo de él. SNOMED CT, a menudo utiliza ECL para expresar este tipo de expansión descendiente. ECL funciona como un lenguaje de consulta compacto para describir conjuntos de conceptos de SNOMED CT. Por ejemplo, la expresión << Heart failure se refiere a "insuficiencia cardíaca y todos los conceptos debajo de ella en la jerarquía". En el diseño de esquema de MongoDB, este patrón se asigna naturalmente a una consulta sobre matrices de ancestros precalculadas. La referencia oficial de ECL de SNOMED define el operador << como "descendiente o sí mismo de", que recupera un concepto y sus subtipos.
Figura 1. Concepto clínico con su jerarquía de padres e hijos.
La solución también demuestra la fundamentación de las notas clínicas. Una nota puede contener hallazgos actuales, antecedentes personales y familiares, acciones planificadas, declaraciones inciertas y hallazgos negados. La aplicación extrae términos clínicos candidatos, busca en SNOMED CT a través de MongoDB, propone conceptos candidatos y almacena las codificaciones revisadas solo después de su confirmación. La codificación almacenada conserva el intervalo de evidencia original, el concepto SNOMED seleccionado, el contexto de la afirmación, el estado del revisor y la ruta ancestral. Las aplicaciones posteriores pueden realizar consultas por significado clínico, no solo por palabras exactas.
Utilice esta solución cuando necesite:
Busque términos clínicos, sinónimos, traducciones e identificadores SNOMED.
Navegue por las vistas de padres, hijos, antepasados, descendientes y relaciones.
Admite la búsqueda de terminología léxica, semántica e híbrida desde una colección de MongoDB.
Amplíe los conjuntos de conceptos con expresiones de jerarquía al estilo ECL, como por ejemplo "todos los descendientes de la insuficiencia cardíaca".
Conciliar las notas clínicas con los criterios de selección de SNOMED CT, considerando la amplitud de la evidencia y la revisión humana.
Almacena las codificaciones SNOMED revisadas con rutas ancestrales para consultas descendentes indexadas.
Este patrón proporciona a los equipos de desarrollo una plataforma operativa unificada para datos terminológicos, búsqueda terminológica, recuperación semántica, consultas jerárquicas, captura de evidencia clínica y codificación auditada. Reduce la necesidad de gestionar sistemas independientes para el almacenamiento, la búsqueda, la recuperación semántica y la navegación gráfica de documentos.
Nota sobre la licencia de SNOMED CT: El repositorio público asociado a esta solución incluye únicamente un pequeño conjunto de datos de muestra. SNOMED CT requiere la licencia correspondiente.
Arquitecturas de Referencia
Esta arquitectura de referencia consta de un flujo de trabajo de navegación y otro de notas clínicas.
La navegación ayuda al usuario de terminología a buscar, inspeccionar y definir el alcance de los conceptos de SNOMED CT. Ground Clinical Note reutiliza la misma capa de recuperación de terminología, utilizando una búsqueda léxica determinista por defecto, para proponer candidatos de SNOMED CT a partir de texto clínico y almacenar únicamente las codificaciones revisadas.
La arquitectura utiliza un conjunto de colecciones de MongoDB:
La colección
snomed-irbdalmacena la vista de terminología de la fuente de verdad.El
snomed-term-searchadmite la búsqueda de terminología de alta calidad.La colección
grounded_notesalmacena la salida de la aplicación revisada, no los datos de terminología de origen.
El contenido de SNOMED CT tiene forma de grafo. Esta arquitectura mantiene las estructuras conectadas juntas en los documentos de MongoDB y utiliza proyecciones de búsqueda y matrices de ancestros para hacerlas operativas.
Arquitectura de un vistazo
Esta implementación parte de un paquete de contenido SNOMED CT autorizado, ya disponible como modelo conceptual JSON. En la demostración actual, el modelo fuente proviene de la distribución nacional española de SNOMED CT utilizada por el Ministerio de Sanidad. El repositorio público incluye únicamente un conjunto de datos de muestra; no redistribuye la terminología completa de SNOMED CT.
La arquitectura es independiente del formato de origen. Si una organización recibe SNOMED CT en formato JSON, puede cargar ese modelo directamente en MongoDB.
Figura 2. MongoDB como autoridad de código, con una puerta de enlace LLM opcional limitada a candidatos.
El modelo objetivo cuenta con las siguientes colecciones de terminología:
snomed-irbdAlmacena cada concepto clínico con sus descripciones, relaciones, padres, hijos, ancestros, estado activo, metadatos de lanzamiento y metadatos de membresía. Las aplicaciones utilizan esta colección para la búsqueda de conceptos, la navegación jerárquica, la inspección de relaciones y la expansión de descendientes.snomed-term-searchAlmacena un documento con capacidad de búsqueda por término, idioma y versión activos. Las aplicaciones utilizan esta proyección para búsqueda léxica, búsqueda semántica, búsqueda híbrida, filtrado por idioma y filtrado por ámbito.
La API de navegación utiliza snomed-term-search para encontrar conceptos coincidentes. A continuación, enriquece los resultados seleccionados de la colección snomed-irbd. Un usuario puede buscar una frase clínica como «insuficiencia cardíaca», examinar el concepto seleccionado, ver conceptos más generales y específicos, y consultar ejemplos de la API para la misma operación.
La API de Grounding reutiliza la capa de recuperación de terminología dentro de un flujo de trabajo de notas clínicas. La recuperación de Grounding utiliza por defecto una búsqueda léxica determinista, mientras que Navigation ofrece modos léxico, semántico e híbrido. El nivel LLM opcional puede ayudar a interpretar el texto y seleccionar entre los candidatos proporcionados por MongoDB, pero no debe crear nuevos identificadores SNOMED CT.
Tras la revisión, la aplicación almacena las codificaciones confirmadas en grounded_notes. Cada codificación conserva el concepto SNOMED CT seleccionado, el texto de la evidencia, el contexto de la aserción, el contexto del sujeto, el estado del revisor y los identificadores de los antecesores. Las aplicaciones posteriores pueden consultar los datos clínicos revisados por su significado, no solo por palabras exactas.
Flujo de trabajo de navegación
Un usuario busca un término clínico como "insuficiencia cardíaca". La aplicación consulta la proyección de búsqueda de términos y devuelve resultados a nivel de concepto agrupados por concepto SNOMED.
Cada resultado muestra:
El término que coincidió con la consulta del usuario
La pantalla preferida para el concepto
El nombre clínico formal
El identificador SNOMED
El estado activo
La categoría semántica
El lanzamiento
La procedencia de la búsqueda
El usuario puede entonces abrir la vista de enfoque del concepto. Esta vista muestra el resumen del concepto, las descripciones, los conceptos principales, los conceptos secundarios, las relaciones, los descendientes, el documento original y los ejemplos de API.
La navegación admite los siguientes modos de búsqueda:
La búsqueda léxica utiliza MongoDB Search para términos exactos, sinónimos, nombres formales, identificadores, prefijos y texto aproximado.
La búsqueda semántica utiliza MongoDB Vector Search, que incrusta automáticamente el campo del término
embedTextcon el4 modelo de referencia voyage-. De este modo, la recuperación por significado se ejecuta en la misma colección sin necesidad de un almacén de vectores o un proceso de incrustación independiente.Labúsqueda híbrida combina la recuperación léxica y vectorial. Si se configura un reordenador de codificadores cruzados de Voyage, la aplicación reordena el conjunto de candidatos fusionados; de lo contrario, recurre al orden de fusión.
La pantalla de búsqueda también admite el alcance semántico. El usuario puede limitar los resultados a un área clínica amplia, como Hallazgo clínico, Procedimiento, Estructura corporal o Sustancia. Asimismo, puede utilizar una expresión derivada, como << 404684003, para restringir los resultados a un concepto y sus conceptos más específicos.
Figura 3. Búsqueda semántica ampliada con ámbitos ECL.
Flujo de trabajo de notas clínicas básicas
El usuario pega una nota clínica. El flujo de trabajo extrae menciones clínicas e información contextual, como hallazgos actuales, negaciones, antecedentes, antecedentes familiares, acciones planificadas, incertidumbre y expresiones temporales.
El flujo de trabajo busca candidatos de SNOMED CT en MongoDB. Devuelve candidatos revisables con información sobre la extensión de la evidencia y el contexto. Un revisor puede aceptar, rechazar o marcar cada candidato para su revisión.
La capa opcional LLM puede ayudar con la interpretación de texto y la selección de candidatos. Solo debe elegir entre los candidatos devueltos por MongoDB. No debe crear nuevos identificadores SNOMED ni persistir codificaciones sin revisión.
Tras la revisión, la aplicación almacena las codificaciones confirmadas en grounded_notes. Cada codificación guardada incluye el intervalo de evidencia, el concepto SNOMED seleccionado, la aserción, el sujeto, el estado y los identificadores de los ancestros. Este patrón permite que las aplicaciones posteriores consulten el significado. Por ejemplo, una aplicación puede encontrar notas revisadas que contengan cualquier descendiente aceptado de un concepto clínico seleccionado.
Figura 4. Fundamentación de una nota clínica - Proceso LLM
Figura 5. Fundamentación de una nota clínica tras la búsqueda de términos con MongoDB.
Fragmentos de API de ejemplo
La solución expone API para los flujos de trabajo de navegación y notas clínicas. Estos fragmentos muestran los patrones de solicitud principales.
Buscar términos y conceptos de SNOMED
Utilice este punto final para buscar en la proyección a nivel de término. La respuesta agrupa los términos coincidentes con los conceptos de SNOMED. Devuelve resultados a nivel de concepto con el término coincidente, la visualización preferida, la categoría semántica y la procedencia de la búsqueda.
POST /api/navigator-search { "query": "heart failure", "languageCode": "en", "mode": "lexical", "limit": 24 }
Utilice el modo léxico cuando el usuario busque mediante un término conocido, sinónimo, nombre formal o identificador SNOMED. La API también admite los modos semántico e híbrido cuando la demostración está configurada para la búsqueda vectorial y la reclasificación de MongoDB.
Ampliar un concepto y sus descendientes
Utilice este punto final para expandir un conjunto de conceptos. SNOMED CT utiliza ECL para describir conjuntos de conceptos. En este ejemplo, la expresión << 84114007 significa «Insuficiencia cardíaca y todos los conceptos más específicos que se encuentran debajo».
POST /api/ecl { "expr": "<< 84114007", "languageCode": "en", "limit": 200 }
La implementación resuelve esta expresión con matrices de ancestros precalculadas en MongoDB. Este patrón permite realizar consultas de descendientes comunes de forma rápida sin necesidad de una base de datos de grafos independiente para la arquitectura de demostración.
Fundamentar una nota clínica para candidatos SNOMED
Utilice este punto final para extraer menciones clínicas candidatas del texto y recuperar candidatos SNOMED delimitados de MongoDB. La respuesta genera resultados revisables sin almacenar códigos automáticamente.
POST /api/nlp-map { "text": "Patient with chronic systolic heart failure and type 2 diabetes. No evidence of chest pain at present.", "languageCode": "en" }
El flujo de trabajo de contextualización detecta menciones clínicas y contexto, como negación, antecedentes, antecedentes familiares, planes y expresiones temporales. MongoDB proporciona los conceptos SNOMED candidatos. Un revisor confirma las codificaciones finales.
Guardar codificaciones confirmadas por el revisor
Utilice este punto final tras su revisión. La aplicación solo almacena las codificaciones confirmadas y las enriquece con identificadores de ancestros para permitir consultas semánticas posteriores.
POST /api/coding-confirm { "text": "Patient with heart failure.", "languageCode": "en", "codings": [ { "mention": "heart failure", "conceptId": "84114007", "displayTerm": "Heart failure", "semanticTag": "disorder", "accepted": true } ] }
El documento guardado conserva el concepto SNOMED seleccionado, el texto de la evidencia, el contexto de la aserción, el estado del revisor y los identificadores de los antepasados. Este esquema permite que las consultas posteriores localicen notas mediante un concepto general o un descendiente específico.
Consultar notas fundamentadas por significado
Utilice este punto final para recuperar las notas revisadas que contengan un concepto SNOMED seleccionado o sus descendientes clínicos.
POST /api/grounded-corpus { "conceptId": "84114007", "includeDescendants": true, "limit": 10 }
Este punto final demuestra el valor añadido de almacenar identificadores de ancestros con codificaciones revisadas. Las aplicaciones pueden consultar el significado clínico en lugar de buscar únicamente palabras exactas.
Enfoque de modelo de datos
SNOMED CT representa datos conectados. Un concepto clínico puede tener muchos términos legibles para humanos, varios conceptos más generales, muchos conceptos más específicos y relaciones formales con otros conceptos.
MongoDB funciona bien para este patrón porque la mayoría de las aplicaciones operativas necesitan una vista centrada en conceptos. Cuando un usuario abre un concepto, la aplicación necesita el identificador del concepto, los términos de visualización, las descripciones, los padres, los hijos, la ruta ancestral, las relaciones, el estado activo y los metadatos de la versión, todo en conjunto.
Este enfoque no elimina la estructura del grafo. Almacena las relaciones y añade matrices optimizadas para consultas, que permiten seguir patrones de navegación comunes. Por ejemplo, cada documento de concepto puede almacenar sus padres directos y su ruta ancestral. Este patrón permite que la aplicación encuentre conceptos más generales, conceptos secundarios y descendientes mediante consultas indexadas en MongoDB.
Por qué funciona este model
Las opciones de diseño que se describen a continuación responden a requisitos operativos específicos: búsquedas rápidas, búsquedas precisas, recorrido rápido de la jerarquía y codificación auditable.
Mantenga los datos conceptuales juntos: Una aplicación de terminología a menudo necesita generar una ficha conceptual completa. Incluir descripciones, resúmenes de relaciones, identificadores de padres, identificadores de hijos e identificadores de ancestros mantiene la vista operativa más útil en un solo documento.
Separar la búsqueda de la terminología de origen: La búsqueda se realiza a nivel de término, no de concepto. Un concepto puede tener múltiples descripciones en distintos idiomas y dialectos. Una proyección a nivel de término permite que MongoDB Search y MongoDB Vector Search clasifiquen el término exacto que coincida, al tiempo que devuelven el concepto canónico.
Precalcular rutas de jerarquía: SNOMED CT tiene una jerarquía compleja. Muchas aplicaciones requieren consultas rápidas de descendientes, como «encontrar este concepto y todos los conceptos más específicos que se encuentran debajo». Almacene los identificadores de los ancestros en cada concepto y en cada codificación clínica revisada. Luego, utilice índices de clave múltiple para las consultas de jerarquía comunes.
Almacene la evidencia con codificaciones revisadas: La codificación aporta mayor valor cuando la aplicación puede explicar su origen. Almacene el concepto SNOMED seleccionado junto con el fragmento de texto clínico, el estado de la aserción, el contexto del sujeto y el estado del revisor. Este patrón admite auditorías, revisiones y consultas posteriores.
Figura 6. Metamodelo SNOMED CT y mapeo de la colección MongoDB
Metamodelo SNOMED CT y mapeo de colecciones de MongoDB
La solución utiliza tres colecciones de terminología, además de una colección de telemetría independiente. Las secciones siguientes describen la estructura del documento y los campos principales de cada una.
La colección snomed-irbd
Utilice snomed-irbd como la vista de fuente de verdad para un concepto SNOMED CT. Cada documento representa un concepto en una versión, que contiene sus descripciones RF2, define relaciones, conceptos padre, conceptos hijo, estado activo, metadatos de la versión y el cierre de ancestro precalculado que impulsa la jerarquía y la subsunción.
{ "conceptId": "44054006", "active": true, "effectiveTime": "20020131", "moduleId": "900000000000207008", "definitionStatusId": "900000000000074008", "descriptions": [ { "id": "73465010", "term": "Diabetes mellitus type II", "typeId": "900000000000013009", "languageCode": "en", "acceptabilityMap": { "900000000000509007": "..." } } ], "relationships": [ { "typeId": "116680003", "destinationId": "73211009", "relationshipGroup": "0", "active": "1" } ], "inferredParentIds": ["73211009"], "inferredAncestorIds": ["73211009", "64572001", "138875005"], "inferredChildIds": ["..."], "relationshipAttributeKeys": ["116680003|73211009"], "memberOfRefsetIds": ["..."], "releaseId": "20260601", "releaseDate": "2026-06-01T00:00:00.000Z", "releaseAppliedAt": "2026-07-06T00:00:00.000Z" }
El snomed-irdb contiene los siguientes campos relevantes:
conceptId: Representa el identificador SNOMED (SCTID); la identidad del concepto estable.descriptions[]Representa los nombres legibles para humanos del concepto. Cada nombre es un sinónimo o el nombre completo (el nombre clínico formal), e indica su idioma y si es preferido o aceptable en ese idioma. Estas entradas se corresponden con las filas de descripción en los archivos de la versión SNOMED CT.relationships[]Representa las relaciones del concepto con otros conceptos. La relación "es un" define la jerarquía. Las relaciones de atributos definen propiedades clínicas como el sitio del hallazgo o el agente causal.relationshipAttributeKeys[]Representa cada relación de atributo como un único valor indexado. Esto permite que la aplicación encuentre conceptos mediante un atributo específico y devuelva resultados con un índice en lugar de realizar un escaneo completo.inferredParentIds,ChildIds,AncestorIds: Representan un cierre precalculado acotado para la subsunción sin recorrido del grafo. Los descendientes se consultan con la cláusula{ inferredAncestorIds: conceptId }en lugar de almacenarse en cada concepto padre.
La prueba de la colección de búsqueda de términos snomed
Utilice snomed-term-search como proyección de búsqueda. Cada documento representa un término de descripción activo en un idioma y una versión, desnormalizado para la búsqueda en MongoDB, el filtrado por ámbito y la búsqueda vectorial de MongoDB integrada automáticamente. Esta estructura permite a los usuarios escribir un sinónimo, una abreviatura, un término localizado, un nombre clínico formal o una frase en lenguaje natural.
El documento de búsqueda repite el contexto conceptual para que cada resultado sea autocontenido. Un resultado puede mostrar el término coincidente, la visualización preferida, la categoría semántica, el estado activo, la versión y el alcance jerárquico sin necesidad de obtener el documento conceptual completo para cada candidato.
{ "conceptId": "44054006", "descriptionId": "116680003", "term": "Type 2 diabetes mellitus", "preferredTerm": "Type 2 diabetes mellitus", "fsn": "Type 2 diabetes mellitus (disorder)", "semanticTag": "disorder", "semanticTagKey":"disorder", "termType": "synonym", "preferred": true, "languageCode": "en", "definitionStatusId": "900000000000074008", "moduleId": "900000000000207008", "effectiveTime": "20020131", "parentIds": ["73211009"], "ancestorIds": ["404684003", "73211009"], "topRoots": ["404684003"], "areaTags": ["disorder"], "releaseId": "20260601", "releaseDate": "2026-06-01T00:00:00.000Z", "embedText": "Type 2 diabetes mellitus | disorder | ..." }
La colección snomed-term-search contiene los siguientes campos relevantes:
conceptId,descriptionId: Enlace de vuelta al concepto y la descripción específica.term,preferredTerm,fsn: Proporcionan el contexto del término y concepto coincidentes, de modo que los resultados de la búsqueda sean autocontenidos.semanticTag,semanticTagKey,termType,preferred: Proporcionan señales de filtrado y clasificación.parentIds,ancestorIds,topRoots,areaTags: Filtros de ámbito sin volver a unirse asnomed-irbd.releaseId,releaseDate,effectiveTime: Proporciona visibilidad de búsqueda y mantenimiento de versiones con alcance de lanzamiento.embedText: Contiene el campo que utilizan las funciones de autoincrustación de MongoDB para la búsqueda vectorial.
Este fragmento explica la decisión de diseño más importante: la proyección de búsqueda se realiza a nivel de término. Muestra por qué una búsqueda de "Nivel alto de azúcar en sangre" aún puede devolver el concepto canónico "Diabetes mellitus".
Con la incrustación automática, solo se almacena el campo embedText legible para humanos, y MongoDB Vector Search genera y mantiene automáticamente la incrustación para ese campo. No se requiere una canalización de incrustación ni un almacén de vectores independiente, ya que la capa semántica reside en la misma colección.
La colección grounded_notes
Utilice grounded_notes para almacenar la salida de la aplicación después de la revisión. Estos documentos no son datos de terminología de origen. Cada documento almacena los siguientes datos:
El texto fuente
El concepto SNOMED CT seleccionado
La evidencia abarca
El contexto de la afirmación, como presente o ausente
El contexto del sujeto, como el paciente o un miembro de la familia.
Estado de la revisión
Los identificadores de los ancestros
El ejemplo que aparece a continuación muestra esta forma.
{ "tenantId": "demo-hospital", "languageCode": "en", "text": "Patient with type 2 diabetes mellitus.", "codings": [ { "conceptId": "44054006", "system": "http://snomed.info/sct", "display": "Type 2 diabetes mellitus", "semanticTag": "disorder", "role": "principal", "target": "Condition.code", "assertion": "present", "subject": "patient", "status": "accepted", "evidence": { "text": "diabetes mellitus tipo 2" }, "ancestorIds": ["44054006","75934005"] } ], "recordedAt": "2026-07-07T16:22:47.210Z", "createdAt": { "$date": "2026-07-07T16:22:47.210Z" } }
Este diseño transforma el texto clínico en información clínica consultable. Posteriormente, una aplicación puede buscar notas revisadas que contengan un concepto o cualquier concepto más específico que se encuentre por debajo en la jerarquía SNOMED CT. Cada código conserva su evidencia, lo que permite al revisor rastrear cada código hasta el texto y contexto exactos que lo generaron, lo cual facilita la auditoría y un uso posterior confiable.
La recopilación de telemetría
Utilice una colección telemetry separada para eventos de búsqueda, solicitudes de jerarquía, actividad de vinculación de notas, retroalimentación y diagnósticos. Mantenga los datos de telemetría fuera del modelo de datos conceptual.
Compilar la solución
El repositorio público incluye el código de la aplicación, los scripts y un conjunto de datos de ejemplo. Los usuarios con licencia pueden reemplazar el conjunto de datos de ejemplo con sus propios archivos de la versión SNOMED CT.
Requisitos previos
Un clúster de MongoDB Atlas con MongoDB Search habilitado.
Acceso a una versión con licencia de SNOMED CT o a un pequeño conjunto de datos de muestra con fines demostrativos.
Node.js y npm para la aplicación de demostración.
Opcional: Configuración de incrustación automatizada de MongoDB Vector Search para búsqueda semántica.
Opcional: Clave de reclasificación de viaje u otro reclasificador configurado para el modo híbrido.
Opcional: Pasarela LLM para extracción delimitada y desambiguación de candidatos.
Procedimiento
Preparar la entrada de terminología autorizada
Utilice la distribución SNOMED CT RF2 de su organización o una distribución JSON. Cargue esta entrada en MongoDB como la colección de conceptos canónicos mediante su propio proceso de ingesta. La terminología predeterminada corresponde a snomed-irdb. Esta colección es un requisito previo.
Los scripts de este repositorio operan sobre una colección canónica precargada; no leen archivos RF2. No publique una versión completa en un repositorio público.
Preparar documentos conceptuales canónicos
La colección canónica almacena cada concepto como un documento centrado en el concepto, que contiene sus descripciones, relaciones, padres, ancestros e información jerárquica. Este esquema contiene metadatos de origen para admitir el estado activo/inactivo, la búsqueda con reconocimiento de versiones, la inspección de descripciones y la navegación de relaciones.
Una vez cargada la colección, normalice los campos para obtener búsquedas consistentes y registre la versión de lanzamiento en cada documento, de modo que los resultados sean reproducibles en diferentes versiones.
NORMALIZE_APPLY=true npm run model:harden # normalize SCTIDs / strings RELEASE_ID_TARGET=20260601 RELEASE_ID_OVERWRITE=true npm run releaseid:stamp
Construir el término sidecar
Genera snomed-term-search a partir de la colección de conceptos canónicos. El contenedor auxiliar almacena un documento de término activo por cada versión, idioma, descripción y concepto. Repite el contexto clave del concepto para que los resultados de la búsqueda no necesiten volver a unirse a la colección de conceptos para cada tarjeta de resultado.
# Curated demo branches TERM_PROJECTION_SCOPE=demo npm run terms:rebuild # Full licensed local release TERM_PROJECTION_SCOPE=full npm run terms:rebuild # Replace documents while preserving index definitions when possible npm run terms:rebuild:replace
Crear índices de MongoDB
Cree los índices btree para la búsqueda de conceptos y la expansión de jerarquías. Cree el índice de búsqueda de MongoDB para la búsqueda de terminología léxica. Cree el índice de búsqueda vectorial de MongoDB para la búsqueda semántica si utiliza el modo semántico o híbrido.
npm run indexes:build
Utilice los siguientes índices de colecciones de fuentes recomendados:
db.getCollection("snomed-irbd").createIndex({ releaseId: 1, conceptId: 1 }) db.getCollection("snomed-irbd").createIndex({ releaseId: 1, active: 1, conceptId: 1 }) db.getCollection("snomed-irbd").createIndex({ releaseId: 1, inferredAncestorIds: 1, active: 1 })
La búsqueda semántica utiliza la incrustación automática de MongoDB Vector Search con voyage-4 como modelo predeterminado. El modo híbrido añade el reordenador Voyage rerank-2.5. Existe una opción de incrustación manual de Voyage como alternativa para clústeres sin incrustación automática.
Configurar búsqueda semántica y reordenamiento
La búsqueda semántica e híbrida utiliza la función de incrustación automática de MongoDB Vector Search. Cree un índice de Vector Search en el campo embedText con un modelo de incrustación configurado en el clúster.
El modo híbrido añade un reordenador de Voyage opcional; configure VOYAGE_API_KEY para habilitarlo. Sin una clave, la búsqueda híbrida sigue funcionando y recurre al orden de fusión. El reordenador prueba primero la URL base configurada, luego la puerta de enlace de Voyage alojada en MongoDB correspondiente a https://ai.mongodb.com/v1 y, finalmente, el punto final de la plataforma nativa de Voyage.
Ejecuta la aplicación de demostración
npm install npm run dev
Utilice un archivo .env.local simple. Mantenga los valores predeterminados operativos en el código o en los archivos de configuración, no como una larga lista de variables de entorno.
MONGODB_URI= MONGODB_DB=terminology VOYAGE_API_KEY= ENABLE_LLM_GROUNDING=false LLM_BASE_URL= LLM_API_KEY= LLM_AUTH_HEADER=api-key LLM_GROUNDING_MODEL=gpt-5.5 # Semantic / hybrid search MONGODB_VECTOR_MODE=autoEmbed MONGODB_VECTOR_INDEX=snomed_voyage_idx MONGODB_VECTOR_AUTO_EMBED_MODEL=voyage-4 VOYAGE_API_KEY= VOYAGE_RERANK_MODEL=rerank-2.5
Validar navegación
Ejecute las siguientes operaciones para verificar su flujo de trabajo de navegación:
Realiza una búsqueda léxica de diabetes e insuficiencia cardíaca.
Realice una búsqueda semántica o híbrida de frases en lenguaje natural como "nivel alto de azúcar en sangre" o "dificultad para respirar".
Abra un concepto e inspeccione el resumen, las descripciones, la jerarquía, las relaciones, los descendientes y el JSON sin procesar.
Ejecuta una expansión de estilo ECL como la expresión
<< 84114007.Verifique que las tarjetas de resultados muestren el término coincidente, el término preferido, la etiqueta semántica, el estado activo y la procedencia de la búsqueda.
Validar nota clínica básica
Ejecute las siguientes operaciones para validar su flujo de trabajo de notas clínicas en tierra:
Cargue una nota clínica sencilla y un ejemplo más detallado de resumen de alta.
Verificar la extracción de segmentos y la detección de contexto para menciones presentes, negadas, de antecedentes familiares, históricas, planificadas e inciertas.
Verifique que el sistema no asigne síntomas genéricos en exceso a descendientes demasiado específicos.
Confirma solo los códigos revisados y guárdalos en la colección
grounded_notes.Ejecute una consulta de MongoDB en
ancestorIdspara comprobar la capacidad de búsqueda operativa.
Lecciones clave
Implementación de SNOMED CT en MongoDB Atlas: Ofrecer terminología clínica en forma de grafo mediante un modelo operativo centrado en documentos que admite búsqueda, jerarquía, relaciones y flujos de trabajo de aplicaciones.
Unifique la navegación terminológica y la búsqueda semántica: utilice MongoDB Search y MongoDB Vector Search para ayudar a los usuarios a encontrar, inspeccionar y delimitar los conceptos de SNOMED CT desde el mismo servicio respaldado por Atlas.
Fundamentar el texto clínico con evidencia revisada: utilizar el servicio de terminología para proponer candidatos SNOMED CT a partir de notas clínicas y, a continuación, almacenar las codificaciones revisadas con evidencia, contexto y rutas ancestrales.
Autores
Francesc Mateu Amengual, MongoDB
Giovanni Rodríguez, MongoDB
Diego Canales, MongoDB
Obtén más información
Descripción general de la búsqueda en MongoDB: Aprenda cómo MongoDB admite la búsqueda de texto completo, el autocompletado, el filtrado, la puntuación y las experiencias de aplicaciones basadas en la búsqueda.
Obtenga SNOMED CT: Revise cómo las organizaciones acceden a SNOMED CT y comprenda el proceso de obtención de licencias para su país o territorio.
Conceptos, descripciones y relaciones de SNOMED CT: Aprenda los componentes básicos de SNOMED CT que esta solución asigna a los documentos de MongoDB.