Saiba como modelar, pesquisar, navegar e fundir a terminologia médica SNOMED CM com o MongoDB Atlas.
Casos de uso: Interoperabilidade
Setores: Saúde
Produtos: MongoDB Atlas, PesquisaMongoDB, VectorSearch MongoDB , Voyage AI
Visão Geral da Solução
Os aplicativos de saúde precisam entender o significado físico, e não apenas armazenar texto técnico. Um médico pode escrever "insuficiência cardíaco", "insuficiência cardíaco" ou "insuficiência no sistema cardíaco". Palavras diferentes podem descrever a mesma ideia prática. A codificação médica oferece aos aplicativos uma maneira padrão de representar esse significado com identificadores estáveis.
As equipes de saúde usam sistemas de codificação diferentes para fins diferentes. Alguns sistemas de codificação agrupam diagnósticos e consultas para análise de relatórios, estatísticas, pagamentos ou consultas. OSNOMED CM se concentra no significado médico dentro do registro de saúde. Pode representar problemas, resultados, procedimentos, estruturas do corpo, organizações, compostos, produtos e muitas outras ideias médicas. O SNOMED TOC oferece suporte a aplicativos para pesquisar, trocar, analisar ou raciocinar sobre informações médicas registradas em um registro eletrônico de saúde.
A SNOMED internacional descreve a SNOMED TOC como uma terminologia médica com conceitos que têm significados únicos, definições formais e organização hierárquica.
O SNOMED CM tem uma estrutura semelhante a um gráfico. Existem mais de 500,000 conceitos específicos em que cada um pode ter várias descrições legíveis por humanos, incluindo sinônimos e traduções. Ela pode ter conceitos principais, conceitos secundários, ancestrais e relacionamentos formais com outros conceitos. O SNOMED CM representa o conteúdo da terminologia por meio de conceitos, descrições e relacionamentos da seguinte forma:
Um conceito representa uma ideia prática.
Uma descrição vincula um termo legível por humanos a esse conceito.
Um relacionamento conecta um conceito a outro.
Essa estrutura é poderosa, mas cria desafios de implementação. As equipes de aplicativos precisam de pesquisa rápida de termo , pesquisa multilíngue, navegação hierárquica, expansão descendente e inspeção de relacionamento . Eles também precisam usar a terminologia do SNOMED em fluxos de trabalho, como revisão de anotações médicas, criação de lista de problemas, suporte a decisões, descoberta de coortes e pesquisa semântica. As implementações tradicionais geralmente divisão essas necessidades em vários sistemas:
Um banco de dados relacional para os arquivos de terminologia.
Um mecanismo de pesquisa para pesquisa de texto.
Um banco de dados de gráficos para transversal hierárquico.
Um banco de dados vetorial para pesquisa semântica.
Esta solução mostra como operacionalizar o SNOMED CM no MongoDB Atlas da seguinte forma:
Armazene cada conceito SNOMED como um documento MongoDB que mantém a identidade do conceito, descrições, relacionamentos, pais, filhos e caminhos ancestrais juntos.
Crie uma projeção de pesquisa em nível de termo para o MongoDB Search e o MongoDB Vector Search.
Use arrays de ancestrais e índices de várias chaves para dar suporte a queries comuns de hierarquia e descendentes sem um banco de dados de grafos separado .
Use o mesmo serviço de terminologia para basear as notas médicas nos candidatos do SNOMED
Armazene codificações revisadas com provas, contexto e caminhos ancestrais.
Por exemplo, um usuário pode pesquisar por "insuficiência" O SNOMED TOC muitas vezes utiliza ECL para expressar esse tipo de expansão descendente. A ECL funciona como uma linguagem de query compacta para descrever conjuntos de conceitos do SNOMED TO. Por exemplo, a expressão << Heart failure refere-se a "insuficiência cardíaca e todos os conceitos abaixo dela na hierarquia". No design de esquema do MongoDB, esse padrão mapeia naturalmente para uma query sobre arrays ancestrais pré-computadas. A referência oficial da ECL do SNOMED define o operador << como "descendente ou próprio de", que recupera um conceito e seus subtipos.
figura 1. Conceito médico com sua hierarquia de pais e filhos
A solução também demonstra o aterrissamento de anotações médicas. Uma anotação pode conter descobertas atuais, histórico passado, histórico familiar, ações planejadas, declarações incertas e descobertas negadas. O aplicação extrai termos físicos candidatos, pesquisa SNOMED CM por meio do MongoDB, propoe conceitos candidatos e armazena codificações revisadas somente após a confirmação. A codificação armazenada mantém a extensão de evidencia original, o conceito SNOMED selecionado, o contexto de asserção, o status do revisor e o caminho do ancestral. Os aplicativos downstream podem fazer queries por significado médico, não apenas por palavras exatas.
Use esta solução quando precisar:
Pesquise termos consultas, sinônimos, traduções e identificadores SNOMED.
Navegue pelas visualizações de pai, filho, ancestral, descendente e relacionamento .
Ofereça suporte à pesquisa de terminologia lexical, semântica e híbrida a partir de uma coleção do MongoDB .
Expanda os conjuntos de conceitos com expressões de hierarquia no estilo ECL, como "todos os descendentes de problemas cardíacos".
Baseie as notas médicas para os candidatos ao SNOMED TOC com abrangencia de evidencias e revisão em humanos.
Armazene codificações SNOMED revisadas com caminhos ancestrais para queries downstream indexadas.
Esse padrão oferece às equipes de aplicação uma plataforma operacional para dados de terminologia, pesquisa de terminologia, recuperação semântica, consultas de hierarquia, captura de pesquisas médicas e resultados de codificação auditados. Reduz a necessidade de executar sistemas separados para armazenamento de documento , pesquisa, recuperação semântica e navegação em estilo de gráfico.
Nota de licenciamento do SNOMED CM: o repositório público associado a esta solução inclui apenas um pequeno conjunto de dados de amostra. O SNOMED CM requer licenciamento adequado.
Arquiteturas de referência
Essa arquitetura de referência consiste em um fluxo de trabalho de navegação e um fluxo de trabalho básico de nota.
A navegação ajuda um usuário de terminologia a pesquisar, inspecionar e abranger conceitos do SNOMED TOC. A Nota Médica Terminológica reutiliza a mesma camada de recuperação de terminologia, usando pesquisa lexical determinística por padrão, para propr candidatos a SNOMED TOC a partir de textos e armazenar apenas códigos analisados.
A arquitetura usa um conjunto de coleções MongoDB :
A coleção
snomed-irbdarmazena a visualização da terminologia da fonte da verdade.O
snomed-term-searchoferece suporte à pesquisa de terminologia de alta qualidade.A coleção
grounded_notesarmazena a saída do aplicação analisado, não os dados de terminologia de origem.
O conteúdo do SNOMED TOC tem a forma de gráfico. Essa arquitetura mantém estruturas conectadas juntas em documentos MongoDB e usa projeções de pesquisa e arrays ancestrais para torná-las operacionais.
Arquitetura em um relance
Essa implementação começa com um pacote de conteúdo SNOMED CM autorizado que já está disponível como um modelo de conceito JSON. Na demonstração atual, o modelo de origem vem da distribuição internacional SNOMED CM da Espanha usada pelo Min stério da Saúde. O repositório público inclui apenas um conjunto de dados de amostra. Ele não redistribui a terminologia completa do SNOMED CM.
A arquitetura é independente do formato de origem. Se uma organização receber SNOMED TOC como JSON, ela poderá carregar esse modelo diretamente no MongoDB.
figura 2. MongoDB como autoridade de código, com um gateway LLM opcional limitado por candidatos.
O modelo de destino tem as seguintes collections de terminologia:
snomed-irbd: Armazena cada conceito crítico com suas descrições, relacionamentos, pais, filhos, ancestrais, status ativo, metadados de lançamento e metadados de associação. Os aplicativos usam essa collection para pesquisa de conceito, navegação hierárquica, inspeção de relacionamento e expansão descendente.snomed-term-search: armazena um documento pesquisável por termo, idioma e versão ativos. Os aplicativos usam essa projeção para pesquisa lexical, pesquisa semântica, pesquisa híbrida, filtragem de idioma e filtragem de escopo.
A API de navegação utiliza o snomed-term-search para encontrar conceitos correspondentes. Em seguida, aprimora os resultados selecionados da coleta snomed-irbd. Um usuário pode pesquisar uma frase médica, como "insuficiência cardíaca", inspecionar o conceito selecionado, visualizar conceitos mais amplos e específicos e abrir exemplos de API para a mesma operação.
A API de aterrissagem reutiliza a camada de recuperação de terminologia dentro de um fluxo de trabalho de anotações médicas. A recuperação de campo padroniza para a pesquisa lexical determinística, enquanto a Navegação oferece modos lexical, semântica e híbrido. A camada LLM opcional pode ajudar a interpretar o texto e a escolher entre os candidatos fornecidos MongoDB, mas não deve criar novos identificadores SNOMED TOC.
Após a análise, as lojas de aplicação confirmaram as codificações em grounded_notes. Cada codificação mantém o conceito SNOMED TOC selecionado, o texto da prova, o contexto da asserção, o contexto do assunto, o status do revisor e os IDs ancestrais. Os aplicativos downstream podem, então, fazer uma query dos dados analisados por significado, não apenas por palavras exatas.
Fluxo de trabalho de navegação
Um usuário pesquisa um termo crítico, como “insuficiência cardíaca”. O aplicação consulta o termo projeção de pesquisa e retorna resultados em nível de conceito agrupados por conceito SNOMED.
Cada resultado mostra:
O termo que correspondeu à query do usuário
A exibição preferida para o conceito
O nome crítico da consulta
O identificador SNOMED
O status ativo
A categoria semântica
O lançamento
A procedência da pesquisa
O usuário pode então abrir a visualização em foco do conceito. Esta visualização mostra o resumo do conceito, descrições, conceitos pai, conceitos filho, relacionamentos, descendentes, documento bruto e exemplos de API.
A navegação suporta estes modos de pesquisa:
A pesquisa lexical usa o MongoDB Search para termos exatos, sinônimos, nomes formais, identificadores, prefixos e texto difusa.
A pesquisa semântica usa o MongoDB Vector Search, que incorpora automaticamente o
embedTextcampo do termo ao4 modelo de referência da viagem. Dessa forma, a recuperação por significado é executada na mesma collection sem exigir um armazenamento de vetor separado ou uma pipeline de incorporação.Apesquisa híbrida combina recuperação lexical e vetorial. Se um reclassificador de codificador cruzado Voyage estiver configurado, o aplicação reclassificará o pool de candidatos codificado; caso contrário, ela voltará à ordem de fusão.
A tela de pesquisa também suporta escopo semântica. Um usuário pode limitar os resultados a uma ampla área médica, como Achado analítico, Procedimento, Estrutura do corpo ou Substância. Um usuário também pode utilizar uma expressão descendente como << 404684003 para restringir resultados a um conceito e seus conceitos mais específicos.
figura 3. Pesquisa semântica expandida com escopos ECL
Fluxo de trabalho de Notas Médicas Fundamentadas
Um usuário cola uma nota médica. O fluxo de trabalho extrai menções médicas e dicas de contexto, como achados atuais, negação, histórico, histórico familiar, ações planejadas, dúvidas e expressões temporais.
O fluxo de trabalho então pesquisa candidatos ao SNOMED TOC por meio do MongoDB. Ele retorna candidatos analisáveis com extensão e contexto de informações. Um revisor pode aceitar, rejeitar ou marcar cada candidato para revisão.
A camada LLM opcional pode ajudar na interpretação do texto e na seleção de candidatos. Ele só deve escolher entre os candidatos retornados pelo MongoDB. Ele não deve criar novos identificadores SNOMED ou persistir codificações sem revisão.
Após análise, o aplicação armazena as codificações confirmadas em grounded_notes. Cada codificação salva inclui a extensão de provas, o conceito SNOMED selecionado, a afirmação, o assunto, o status e os IDs de ancestralidade. Esse padrão permite que os aplicativos downstream consultem o significado. Por exemplo, um aplicação pode encontrar notas revisadas contendo qualquer descendente aceito de um conceito crítico selecionado.
figura 4. Fundição de uma nota médica - Processo LLM
figura 5. Conectando uma nota médica após a pesquisa de termos com o MongoDB
Trechos de exemplo de API
A solução expõe APIs para os fluxos de trabalho de Navegação e Notas Médicas em Terra. Esses trechos mostram os principais padrões de solicitação.
Pesquise termos e conceitos do SNOMED
Use esse endpoint para pesquisar a projeção em nível de termo. A resposta agrupa os termos correspondentes aos conceitos do SNOMED. Ela retorna resultados em nível de conceito com o termo correspondente , exibição preferencial, categoria semântica e procedência da pesquisa.
POST /api/navigator-search { "query": "heart failure", "languageCode": "en", "mode": "lexical", "limit": 24 }
Use o modo lexical quando o usuário pesquisar por um termo conhecido, sinônimo, nome oficial ou identificador SNOMED. A API também suporta modos semântica e híbrida quando a demonstração é configurada para MongoDB Vector Search e reclassificação.
Expandir um conceito e seus descendentes
Use este endpoint para expandir um conjunto de conceitos. SNOMED CM usa ECL para descrever conjuntos de conceitos. Neste exemplo, a expressão << 84114007 significa "Insuficiência cardíaca e todos os conceitos mais específicos abaixo dela".
POST /api/ecl { "expr": "<< 84114007", "languageCode": "en", "limit": 200 }
A implementação resolve essa expressão com arrays ancestrais pré-computadas no MongoDB. Esse padrão agiliza as queries de descendentes comuns sem exigir um banco de dados de grafos separado para a arquitetura de demonstração.
Fundar uma nota prática para os candidatos do SNOMED
Use esse endpoint para extrair menções médicas de candidatos do texto e recuperar candidatos SNOMED limitados do MongoDB. A resposta gera uma saída analisável sem códigos persistentes automaticamente.
POST /api/nlp-map { "text": "Patient with chronic systolic heart failure and type 2 diabetes. No evidence of chest pain at present.", "languageCode": "en" }
O fluxo de trabalho de aterrissagem detecta menções médicas e contexto, como negação, histórico, histórico familiar, planos e expressões temporais. O MongoDB fornece conceitos SNOMED aos candidatos. Um revisor confirma os códigos finais.
Salvar codificações confirmadas pelo revisor
Use esse endpoint após a revisão. O aplicação armazena apenas códigos confirmados e os enriqueça com IDs de ancestrais para permitir queries semânticas downstream.
POST /api/coding-confirm { "text": "Patient with heart failure.", "languageCode": "en", "codings": [ { "mention": "heart failure", "conceptId": "84114007", "displayTerm": "Heart failure", "semanticTag": "disorder", "accepted": true } ] }
O documento salvo mantém o conceito SNOMED selecionado, o texto de prova, o contexto da afirmação, o status do revisor e os IDs de ancestral. Esse esquema permite que queries downstream localizem anotações por um conceito geral ou um descendente específico.
Consultar Notas Baseadas por Significado
Use esse endpoint para recuperar anotações revisadas que contêm um conceito SNOMED selecionado ou seus descendentes físicos.
POST /api/grounded-corpus { "conceptId": "84114007", "includeDescendants": true, "limit": 10 }
Esse endpoint demonstra o valor downstream de armazenar IDs ancestrais com codificações revisadas. Os aplicativos podem consultar o significado médico em vez de pesquisar apenas palavras exatas.
Abordagem do modelo de dados
SNOMED CM representa dados conectados. Um conceito médico pode ter muitos termos legíveis por humanos, conceitos mais amplos, conceitos mais específicos e relacionamentos formais com outros conceitos.
O MongoDB funciona bem para esse padrão porque a maioria dos aplicativos operacionais precisa de uma visualização centralizada em conceitos. Quando um usuário abre um conceito, o aplicação precisa do identificador de conceito, termos de exibição, descrições, pais, filhos, caminho do ancestral, relacionamentos, status ativo e metadados de versão juntos.
Essa abordagem não remove a estrutura do gráfico. Ele armazena os relacionamentos e adiciona arrays compatíveis com query para padrões de navegação comuns. Por exemplo, cada documento de conceito pode armazenar seus pais diretos e seu caminho ancestral. Esse padrão permite que o aplicação encontre conceitos mais amplos, conceitos filhos e descendentes com consultas indexadas do MongoDB .
Por que esse model funciona
As opções de design abaixo atendem a requisitos operacionais específicos: pesquisas rápidas, pesquisas precisas, rápida passagem de hierarquia e codificação auditável.
Manter dados de conceito juntos: um aplicação de terminologia geralmente precisa renderizar um cartão de conceito completo. A incorporação de descrições, resumos de relacionamento , IDs principais, IDs filhos e IDs ancestrais mantém a exibição operacional mais útil em um documento.
Separe a terminologia da pesquisa da origem: A pesquisa é em nível de termo, não em nível de conceito. Um conceito pode ter muitas descrições em idiomas e dialetos. Uma projeção em nível de termo permite que o MongoDB Search e o MongoDB Vector Search classifiquem o termo exato que correspondeu enquanto ainda retorna o conceito canônico.
Caminhos de hierarquia de pré-computação: O SNOMED CM tem uma hierarquia rica. Muitos aplicativos precisam de consultas descendentes rápidas, como "encontre este conceito e todos os conceitos mais específicos abaixo dele". Armazene IDs ancestrais em cada conceito e cada codificação médica revisada. Em seguida, use índices de múltiplas chaves para queries de hierarquia comuns.
Armazene provascom codificações revisadas: A codificação oferece mais valor quando o aplicação pode explicar sua origem. Armazene o conceito SNOMED selecionado junto com a extensão de texto crítico, status de afirmação, contexto do assunto e status do revisor. Esse padrão oferece suporte a queries de auditar, revisão e downstream .
figura 6. Metamodelo SNOMED e mapeamento collection do MongoDB
Metamodelo SNOMED CM e mapeamento de collections MongoDB
A solução usa três coleções de terminologia, além de uma coleção de telemetria separada. As seções abaixo descrevem a forma do documento e os campos principais de cada uma.
A collection snomed-irbd
Use snomed-irbd como a visualização da fonte da verdade para um conceito do SNOMED TOC. Cada documento representa um conceito em uma versão, contendo suas descrições de RF2, definindo relacionamentos, conceitos principais, conceitos secundários, status ativo, metadados da versão e o fechamento ancestral pré-computado que alimenta a hierarquia e a subsunção.
{ "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" }
O snomed-irdb contém os seguintes campos relevantes:
conceptId: Representa o identificador SNOMED (SCTID); a identidade do conceito estável.descriptions[]: Representa os nomes legíveis por humanos para o conceito. Cada nome é um sinônimo ou o nome totalmente especificado (o nome comercial formal) e registra seu idioma e se é preferido ou aceitável nesse idioma. Essas entradas são mapeadas para as linhas de descrição nos arquivos de versão do SNOMED TOrelationships[]: representa as relações do conceito com outros conceitos. "Is a" relacionamento define a hierarquia. As relações de atributos definem propriedades médicas , como localizar um local ou um agente causal .relationshipAttributeKeys[]: Representa cada relacionamento de atributo como um único valor indexado. Isso permite que o aplicação encontre conceitos por um atributo específico e retorne resultados com um índice em vez de uma verificação completa.inferredParentIds,ChildIds,AncestorIds: representam fechamento pré-computado limitado para subsunção sem atravessamento do gráfico. Os descendentes são consultados com a cláusula{ inferredAncestorIds: conceptId }em vez de armazenados em cada conceito pai.
O teste de collection do snomed-term-search
Utilize o snomed-term-search como a projeção de pesquisa. Cada documento representa um termo de descrição ativo em um idioma e uma versão, desnormalizado para o MongoDB Search, filtragem de escopo e Vector Search do MongoDB incorporada automaticamente. Essa estrutura permite que os usuários digitem um sinônimo, abreviação, termo localizado, nome físico oficial ou frase de linguagem natural.
O documento de pesquisa repete o contexto do conceito para tornar cada resultado da pesquisa independente. Um resultado pode mostrar o termo correspondente , a exibição preferencial, a categoria semântica, o status ativo, a liberação e o escopo da hierarquia sem buscar o documento de conceito 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 | ..." }
A coleção snomed-term-search contém os seguintes campos relevantes:
conceptId,descriptionId: Faça o link de volta para o conceito e a descrição específica.term,preferredTerm,fsn: forneça termo correspondentes e contexto de conceito, para que os resultados da pesquisa sejam autônomos.semanticTag,semanticTagKey,termType,preferred: fornecem sinais de filtragem e classificação.parentIds,ancestorIds,topRoots,areaTags: Filtros de escopo sem ligar de volta parasnomed-irbd.releaseId,releaseDate,effectiveTime: forneça uma pesquisa com escopo de lançamento e visibilidade de manutenção de versão.embedText: contém o campo que as incorporações automáticas do MongoDB usam para Vector Search.
Este trecho explica a escolha de design mais importante: a projeção de pesquisa é em nível de termo. Mostra por que uma pesquisa por “açúcar alto no corpo” ainda pode retornar o conceito canônico de “diabetes Mistos”
Com a incorporação automática, você armazena somente o campo embedText legível por humanos, e o MongoDB Vector Search gera e mantém a incorporação desse campo automaticamente. Você não precisa de um pipeline de incorporação separado ou de um armazenamento de vetores, porque a camada semântica reside na mesma collection.
A coleçãogrounded_notes
Use grounded_notes para armazenar o resultado do aplicação após a revisão. Esses documentos não são dados de terminologia de origem. Cada documento armazena os seguintes dados:
O texto fonte
O conceito SNOMED CM selecionado
A extensão de informações
O contexto da afirmação, como presente ou ausente
O contexto do assunto, como doente ou membro da família
O status da revisão
Os IDs ancestrais
O exemplo abaixo mostra 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 design transforma o texto médico em significado médico consultável. Um aplicação pode pesquisar posteriormente notas revisadas que contenham um conceito ou qualquer conceito mais específico abaixo dele na hierarquia do SNOMED CM. Cada codificação mantém suas provas, para que um revisor possa rastrear cada código de volta ao texto e contexto exatos que o produziram, o que suporta auditar e uso seguro do downstream.
A coleção de telemetria
Use uma coleção telemetry separada para eventos de pesquisa, solicitações de hierarquia, atividade de anotação, feedback e diagnóstico. Mantenha os dados de telemetria fora do modelo de dados conceitual.
Construir a solução
O repositório público inclui o código do aplicação , os scripts e um conjunto de dados de amostra. Usuários autorizados podem substituir o conjunto de dados de amostra por seus próprios arquivos de versão do SNOMED CM.
Pré-requisitos
Um cluster MongoDB Atlas com o MongoDB Search ativado.
Acesso a uma versão licenciada do SNOMED CM ou a um pequeno conjunto de dados de amostra para fins de demonstração.
Node.js e npm para o aplicação de demonstração .
Opcional: configuração de incorporação automatizada do MongoDB Vector Search para pesquisa semântica.
Opcional: chave de reclassificação de viagem ou outro reranker configurado para o modo híbrido.
Opcional: gateway LLM para extração limitada e desambiguação de candidatos.
Procedimento
Preparar entrada de terminologia licenciada
Use a distribuição SNOMED CM RF2 da sua organização ou uma distribuição JSON. Carregue esta entrada no MongoDB como a coleção de conceitos canônica usando seu próprio processo de ingestão. A terminologia padrão corresponde a snomed-irdb. Esta collection é um pré-requisito.
Os scripts neste repositório operam em uma coleção canônica pré-carregada; eles não leem arquivos RF2. Não confirme uma versão completa em um repositório público.
Preparar documentos de conceito canônicos
A coleção canônica armazena cada conceito como um documento centralizado em conceitos , contendo suas descrições, relacionamentos, pais, ancestrais e informações hierárquicas. Esse esquema contém metadados de origem para suportar o status ativo e inativo, pesquisa com reconhecimento de versão, inspeção de descrição e navegação de relacionamento .
Depois de carregar a coleção, normalize os campos para pesquisas consistentes e registre a versão de lançamento em cada documento, para que os resultados sejam reproduzíveis entre versões.
NORMALIZE_APPLY=true npm run model:harden # normalize SCTIDs / strings RELEASE_ID_TARGET=20260601 RELEASE_ID_OVERWRITE=true npm run releaseid:stamp
Crie o termo sidecar
Gere snomed-term-search a partir da coleção de conceitos canônicos. O sidecar armazena um documento de termo ativo por versão, idioma, descrição e conceito. Ele repete o contexto do conceito chave para que os resultados da pesquisa não precisem voltar à coleção de conceitos para cada cartão 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
Criar índices MongoDB
Crie os índices btree para pesquisa de conceito e expansão hierárquica. Crie o índice do MongoDB Search para pesquisa de terminologia lexical. Crie o índice MongoDB Vector Search para pesquisa semântica se você usar o modo semântica ou híbrido.
npm run indexes:build
Use os seguintes índices de collection de origem 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 })
A pesquisa semântica utiliza a incorporação automática do MongoDB Vector Search com priority-4 como o modelo padrão. O modo híbrido adiciona o reranker Voyage-2.5. Existe um fallback manual de incorporação de Voyage para clusters sem incorporação automática.
Configurar pesquisa semântica & reclassificação
A pesquisa semântica e híbrida usa a incorporação automática do MongoDB Vector Search . Crie um índice do Vector Search no campo embedText com um modelo de incorporação configurado no cluster.
O modo híbrido adiciona um reranker Voyage opcional; defina HOYAGE_API_KEY para habilitá-la. Sem uma chave, a pesquisa híbrida ainda funciona e volta à ordem de fusão. O reranker tenta seu URL base configurado , depois o gateway Voyage hospedado no MongoDB correspondente a https://ai.mongodb.com/v }1 e, em seguida, o endpoint de plataforma nativa do próprio Voyage.
Executar o aplicação de demonstração
npm install npm run dev
Use um arquivo .env.local fino. Mantenha os padrões operacionais no código ou nos arquivos de configuração, não como uma longa lista de variáveis de ambiente.
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 navegação
Execute as seguintes operações para verificar seu fluxo de trabalho de navegação:
Faz uma pesquisa lexical para definir entre diabete e falha coronária.
Faça uma pesquisa semântica ou híbrida para frases de linguagem natural, como alto nível de nível de açúcar no corpo ou problemas para expirar.
Abra um conceito e inspecione o resumo, as descrições, a hierarquia, os relacionamentos, os descendentes e o JSON bruto.
Execute uma expansão no estilo da ECL, como a expressão
<< 84114007.Verifique se os cartões de resultados mostram o termo correspondente , o termo preferencial , a tag semântica, o status ativo e a procedência da pesquisa.
Validar Nota Médica Funda
Execute as seguintes operações para validar seu fluxo de trabalho da Nota Médica Baseada:
Carregue uma nota médica simples e um exemplo de resumo de alta mais completo.
Verifique a extração de extensão e a detecção de contexto para menções presentes, negadas, de histórico familiar, históricas, planejadas e incertas.
Verifique se o sistema não sobrecodifica sinais genéricos para descendentes excessivamente específicos.
Confirme apenas os códigos analisados e salve-os na coleção
grounded_notes.Execute uma query do MongoDB no
ancestorIdspara provar a capacidade de pesquisa operacional.
Principais Aprendizados
Operacionalize o SNOMED CM no MongoDB Atlas: sirva terminologia médica em forma de gráfico por meio de um modelo operacional centralizado em documentos que oferece suporte a fluxos de trabalho de pesquisa, hierarquia, relacionamentos e aplicação .
Unifique a navegação terminológica e a pesquisa semântica: use o MongoDB Search e o MongoDB Vector Search para ajudar os usuários a encontrar, inspecionar e definir o escopo dos conceitos de SNOMED TOC do mesmo serviço apoiado pelo Atlas.
Baseie o texto crítico com pesquisas revisadas: Use o serviço de terminologia para indicar candidatos a SNOMED TOC a partir de anotações médicas e, em seguida, armazene as codificações revisadas com provas, contexto e caminhos ancestrais.
Autores
Francesc Mateu Amengual, MongoDB
Giovanni Rodríguez, MongoDB
Diego Canales, MongoDB
Saiba mais
Visão geral da pesquisa do MongoDB : saiba como o MongoDB oferece suporte à pesquisa de texto completo, preenchimento automático, filtragem, pontuação e experiências de aplicação orientadas por pesquisa.
Obtenha o SNOMED CM: revise como as organizações acessam o SNOMED CM e entenda o caminho do licenciamento para seu país ou território.
Conceitos, descrições e relacionamentos do SNOMED TOC: Aprenda os blocos de construção básicos do SNOMED TOC que esta solução mapeia para documentos do MongoDB .