Camada de dados operacionais FHIR híbrido

Visão Geral da Solução

Este projeto desenvolve um padrão ODL híbridoFHIR para saúde. O objetivo principal é criar uma loja operacional única e de alto desempenho que habilite os serviços web ao cliente . Além disso, o design expõe endpoints compatíveis com FHIR para os recursos no escopo, para que recursos futuros possam ser criados usando a API REST FHIR em vez de novos serviços personalizados.

Na verdade, o ODL usa o MongoDB Atlas como um banco de dados flexível e escalável que armazena recursos, como Patient ou Encounter, em um formato estruturado de três blocos. Isso inclui:

• A representação canônica FHIR quando existe um mapeamento.

• Campos adicionais específicos do aplicativo.

• Campos de pesquisa pré-indexados otimizados para o desempenho da consulta.

Como os mapeamentos são definidos como FHIR first, os campos alinhados com FHIR são armazenados usando a estrutura padrão, enquanto os atributos restantes são mantidos em blocos de aplicação separados. Essa estrutura híbrida preserva a interoperabilidade sem forçar a solução a se comportar como um servidor FHIR completo .

O backend usa FastAPI e expõe duas classes de APIs:

• API de aplicativos: implementa os endpoints operacionais do cliente, por exemplo , pesquisa de pacientes, pesquisa de casos ou serviços de identificador local, usando o ODL como backend compartilhado.

• API FHIR: Fornece pesquisa compatível com FHIR para um subconjunto definido de recursos, como Patient e,Encounter reutilizando o mesmo modelo de envelope e índices. Ele foi projetado como uma faceta FHIR prática e não como um servidor FHIR completo e orientado por perfis.

O frontend usa Next.js e inclui um demonstrador de API interativo, para que as equipes possam experimentar endpoints de aplicação e queries no estilo FHIR juntas.

Para demonstração e desenvolvimento, o ODL pode gerar conjuntos de dados sintéticos sintéticos, permitindo testes realistas sem expor dados reais de pacientes.

Arquiteturas de referência

A arquitetura se concentra no FHIR Híbrido ODL, uma abordagem de modelo de dados de referência que oferece suporte a padrões de acesso operacional personalizados e acesso compatível com FHIR ao mesmo conjunto de dados. Em vez de duplicar dados, essa abordagem indexa informações valiosas para consultas operacionais e mantém o recurso FHIR completo.

O caso de uso origina-se de um desafio de cliente do mundo real envolvendo uma grande instituição de saúde que opera várias plataformas de EHR. Cada sistema oferecia serviços de acesso a pacientes de forma independente, levando a um acesso fragmentado a dados, lógica duplicada e ausência de interoperabilidade semântica.

Para simplificar isso, a instituição introduziu um ODL para centralizar o acesso a dados consultas e fornecer serviços de MDM compartilhados, sem interromper os aplicativos existentes.

Essa situação criou uma oportunidade de mudança para as melhores práticas do setor, adotando o FHIR como linguagem comum, em vez de redefinir as estruturas de dados e a semântica do nada. Ao projetar o modelo de dados ODL como FHIR-first, a organização evitou “reinventar a roda” para conceitos centrais, como pacientes e consultas. Ele também se alinhou com as definições padrão de recursos, tornando-o um modelo em potencial para outros na campo.

A arquitetura de referência mostra como as empresas de saúde podem unificar diferentes fontes de dados, oferecer suporte a processos personalizados e fornecer APIs de alto desempenho usando o MongoDB Atlas. A interface é dividida em abas, cada aba exibindo um recurso específico da arquitetura.

figura 1. Arquitetura de referência ODL híbrido FHIR

Inicialmente, a seção de mapeamentos mostra como os campos de dados de saúde legado são mapeados para o modelo de dados ODL, que é projetado em torno de um esquema centralizado em FHIR. Cada documento armazena:

• Um recurso FHIR canônico (quando existe um mapeamento FHIR)

• Campos específicos do aplicativo exigidos pelos fluxos de trabalho atuais

• Campos otimizados para pesquisa usados pelas APIs

Os usuários podem procurar um conjunto completo de mapeamentos de campo em entidades como Patient e Encounter em uma tabela interativa. Isso os ajuda a entender quais campos vêm da especificação FHIR e quais são modelados como campos de aplicação ou pesquisa. Essa estratégia de mapeamento facilita o rastreamento da linhagem de dados e a avaliação do alinhamento com os padrões.

figura 2. Aba Mapeamentos na demonstração do Híbrido FHIR ODL

A plataforma inclui um gerador integrado que cria dados internos sintéticos para testes de armazenamento e recuperação, permitindo que as equipes testem a funcionalidade. Os usuários podem personalizar o conteúdo sintético, incluindo o número de pacientes, consultas por usuário, profissionais e equipes de saúde.

Personagem 3: criador de dados físicos sintéticos

Depois que os dados são preenchidos, a seção Visualizador de Dados permite que os usuários examinem os recursos FHIR armazenados no MongoDB. Ele mostra o conteúdo canônico do FHIR e os campos adicionais do ODL em um só lugar, explicando como os dados padrão e operacionais coexistem.

A seção API do cliente integra sistemas de saúde legado à plataforma. Um testador de API permite que os usuários chamem MDM específico do cliente e endpoints operacionais. Ao selecionar um endpoint e inserir os parâmetros necessários, os usuários podem executar a query e exibir a resposta formatada conforme os sistemas personalizados esperam.

Por fim, a seção Testador de API FHIR permite que os usuários realizem pesquisas padrão FHIR no conjunto de dados subjacente. Os resultados exibem o pipeline de consulta MongoDB e a resposta FHIR. Essa exibição destaca como a plataforma mantém a saída compatível com o padrão FHIR, fornece insights de desempenho e fornece detalhes de depuração.

Abordagem do modelo de dados

A arquitetura é construída em torno de um esquema ODL baseado em FHIR armazenado no MongoDB. Em vez de dispersar os dados dos pacientes e consultas em muitas tabelas, cada registro é mantido como um único documento com três seções. Cada seção serve a um propósito específico dentro do ODL:

• resource para o conteúdo FHIR canônico: contém um objeto R4 FHIR válido, como Patient Encounterou. Esse bloco pode ser retornado diretamente por endpoints no estilo FHIR sem transformação adicional.

• app para os metadados do aplicação : contém campos exigidos pelos fluxos de trabalho, mas que fazem parte do recurso FHIR base. Inclui campos como códigos internos, sinalizadores de classificação ou outros atributos específicos do cliente.

• search para a superfície de query desnormalizada: nivela os atributos usados com mais frequência em queries, incluindo identificadores como nomes, datas principais, referências de organização ou localização. Ele também transforma as chaves de relacionamento em campos fáceis de indexar e usar para a camada da API.

Abaixo, você pode encontrar um exemplo de JSON comentado para o recurso Encounter:

{
   "_id": "ObjectId",
   "tenant": "tenant-1",
   "resourceType": "Encounter",
   // 1 Canonical FHIR block
   "resource": {
      "resourceType": "Encounter",
      "id": "036fcfcd-797c-4ae2-a30f-49226357deb2",
      ...,
      "status": "onhold",
      "class": {
         "code": "EMER"
      },
      "serviceType": {
         ...
      },
      "period": {
         "start": "2025-10-31T17:43:00",
         "end": "2025-11-02T17:43:00"
      },
      "serviceProvider": {},
      "hospitalization": {},
      "participant": [],
      "location": [],
      "type": [
         { ... }
      ]
   },
   // 2 Application block
   "app": {
      "caseNum": "QH-1761928980-83",
      "doctorCode": "DR100",
      "specialistCode": "DR100",
      ...,
      "sourceIndicator": "SELF",
      "patientGroup": "G2"
   },
   // 3 Search block
   "search": {
      "start": "2025-10-31T17:43:00",
      "end": "2025-11-02T17:43:00",
      "local_id": "A108548(0)",
      ...,
      "caseNum": "QH-1761928980-83",
      "statusCode": "onhold",
      "caseType": "E"
   }
}

Construir a solução

Para obter instruções de configuração detalhadas, siga as etapas descritas na README deste repositório GitHub. Este repositório hospeda o backend e o frontend para esta demonstração.

Para reproduzir esta demonstração em seu próprio ambiente, siga estas etapas:

git clone https://github.com/mongodb-industry-solutions/hybrid-fhir-odl.git
cd hybrid-odl

MONGODB_URI=mongodb+srv://<user>:<password>@<cluster-url>/?retryWrites=true&w=majority
MONGODB_DB=fhir_demo
MONGODB_COLLECTION=fhir
MONGODB_TENANT=tenant-1

NEXT_PUBLIC_ENABLE_FHIR = true
BACKEND_URL=http://localhost:3100

make install

make backend

make frontend

Principais Aprendizados

• Modernizar sistemas de saúde legado : esta solução mostra como os Hospitais podem atualizar sua infraestrutura de dados consultas sem ter que abandonar seus fluxos de trabalho operacionais. Em vez de exigir que as organizações mantenham seus serviços totalmente personalizados ou mudem totalmente para o FHIR, essa abordagem permite integrar esses sistemas de forma incremental. Os dados permanecem disponíveis como recursos FHIR, e endpoints de aplicação personalizados e padrões de query existentes continuam a funcionar por meio da camada da API do aplicação . Os Hospitais que usam essa solução podem modernização rolante sua infraestrutura, movendo equipes médicas e sistemas de parceiros em seu próprio tempo.

• Otimizar o desempenho dos dados consultas: essa abordagem permite que os dados FHIR permaneçam inalterados no bloco de recursos para conformidade com os padrões, enquanto as informações do aplicação residem em atributos de alto uso, indexados para desempenho de pesquisa mais rápido. O sistema é apropriado para painéis específicos em tempo real, análises operacionais e pesquisas rápidas durante o registro, a triagem e o gerenciamento de camas.

• Acelerar a interoperabilidade e a produtividade do desenvolvedor: a arquitetura de API dupla, a geração de dados sintéticos integrada e as ferramentas interativas de teste de API ajudam as equipes a criar protótipos, validação e implantação rápidas de soluções compatíveis com FHIR sem interromper os processos internas do internamento.

Autores

• Patricia Renart Carniceiro, MongoDB

• Francesc Mateu Amengual, MongoDB

Saiba mais

• Assistência médica viabilizada por AI com a MongoDB e a Microsoft

• Varejo impulsionado por IA: personalização e precisão

• RAG sensível ao contexto para documentos técnicos