Camada Híbrida de Dados Operacionais FHIR

Visão Geral da Solução

Este projeto desenvolve um padrão FHIR híbrido ODL para cuidados de saúde. O objetivo primário é criar um armazenamento único e operacional de alto desempenho que potencialize os serviços web para o cliente. Além disso, o projeto expõe compatibilidade com FHIR pontos de extremidade para os recursos em escopo, para que recursos futuros possam ser criados usando a REST API do FHIR em vez de novos serviços personalizados.

No seu núcleo, a ODL usa o MongoDB Atlas como um banco de dados flexível e dimensionável que armazena recursos, como Patient ou Encounter, em um formato estruturado de três blocos. Isso inclui:

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

• Campos adicionais específicos do aplicativo.

• Campos de pesquisa com índices prévios otimizados para o desempenho da query.

Como os mapeamentos são definidos primeiro por FHIR, os campos alinhados com FHIR são armazenados usando a estrutura padrão, enquanto os atributos restantes são mantidos em blocos de aplicativo 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 famílias de APIs:

• Aplicativo API: implementa os pontos de extremidade operacionais do cliente, por exemplo, pesquisa de pacientes, pesquisa de casos ou serviços de identificador local, usando o ODL como um 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 fachada FHIR pragmática, não como um servidor FHIR completo e orientado por perfis.

O frontend utiliza Next.js e inclui um demonstrador de API interativo, para que as equipes possam testar pontos de extremidade de aplicativos e queries no estilo FHIR em conjunto.

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

Arquiteturas de referência

A arquitetura se concentra no FHIR Hybrid 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 sobre o mesmo conjunto de dados. Em vez de duplicar dados, essa abordagem indexa informações valiosas para queries operacionais e mantém o recurso FHIR completo.

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

Para simplificar isso, essa instituição introduziu um ODL para centralizar o acesso aos dados clínicos e fornecer serviços MDM compartilhados, sem interromper os aplicativos existentes.

Essa situação criou uma oportunidade de mudar para as práticas recomendadas do setor, adotando a FHIR como linguagem comum, em vez de redefinir estruturas de dados e semântica a partir do nada. Ao projetar o modelo de dados ODL com abordagem FHIR-first, a organização evitou "reinventar a roda" para conceitos essenciais, como pacientes e atendimentos. Além disso, alinhou-se às definições padronizadas de recursos, tornando-se um modelo potencial para outras organizações do setor.

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

Figura 1. Arquitetura de referência FHIR Hybrid ODL

Inicialmente, a seção de mapeamentos mostra como os campos de dados legados da área de saúde são mapeados no modelo de dados ODL, que é projetado em torno de um esquema centrado no 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 navegar por 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 aplicativo 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 Hybrid FHIR ODL

A plataforma inclui um gerador integrado que cria dados clínicos 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 paciente, profissionais e equipes de atendimento.

Figura 3. Gerador de dados clínicos sintéticos

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

A seção API do cliente integra sistemas legados de saúde à plataforma. Um testador de API permite que os usuários chamem pontos de extremidade operacionais e de MDM específicos do cliente. Ao selecionar um ponto de extremidade e inserir os parâmetros necessários, os usuários podem executar a query e ver a resposta de formato, conforme os sistemas personalizados esperam.

Por fim, a seção FHIR API Tester permite que os usuários realizem pesquisas padrão FHIR no conjunto de dados subjacente. Os resultados exibem o pipeline de query do MongoDB e a resposta do FHIR. Essa visualização destaca como a plataforma mantém a saída em conformidade com o padrão FHIR, fornece perspicácias de desempenho e detalhes de depuração.

Abordagem do modelo de dados

A arquitetura é criada em torno de um esquema ODL centrado em FHIR armazenado no MongoDB. Em vez de distribuir os dados de pacientes e queries por 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 ou Encounter. Esse bloco pode ser retornado diretamente por pontos de extremidade no estilo FHIR sem transformação adicional.

• app para os metadados do aplicativo: contém campos que são necessários pelos fluxos de trabalho, mas fazem parte do recurso FHIR base. Ele 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: achata os atributos usados com mais frequência em queries, incluindo identificadores como nomes, datas importantes, organização ou referências de localização. Também transforma as chaves de relacionamento em campos de fácil indexação e uso para a camada de API.

Abaixo, você pode encontrar um exemplo comentado de JSON 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 detalhadas de configuração, siga os passos descritos no README deste repositório do GitHub. Esse repositório hospeda o backend e o frontend desta 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 legados: esta solução mostra como os hospitais podem atualizar sua infraestrutura de dados clínicos sem ter que interromper fluxos de trabalho operacionais. Em vez de exigir que as instituições mantenham os serviços totalmente personalizados ou mudem totalmente para o FHIR, essa abordagem permite integrar esses sistemas de forma gradual. Os dados permanecem disponíveis como recursos FHIR, e os pontos de extremidade do aplicativo personalizado e os padrões de query existentes continuam a funcionar por meio da camada de API do aplicativo. Os hospitais que utilizam esta solução podem modernizar sua infraestrutura aos poucos, movendo equipes clínicas e sistemas parceiros no seu próprio ritmo.

• Otimize o desempenho de dados clínicos: esta abordagem permite que os dados FHIR permaneçam inalterados no bloco de recurso para compliance com os padrões, enquanto as informações do aplicativo residem em atributos de alto uso, indexados para desempenho de pesquisa mais rápido. O sistema é apropriado para dashboards clínicos em tempo real, análise operacional e pesquisas rápidas durante o registro, triagem e gerenciamento de leitos.

• Acelere a interoperabilidade e a produtividade dos desenvolvedores: 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 prototipar, validar e implantar rapidamente soluções compatíveis com FHIR sem interromper os processos hospitalares existentes.

Autores

• Patricia Renart Carnicero, 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