Suporte a decisões clínicas para detecção de lacunas de atendimento

MongoDB Atlas: principais funcionalidades

Projetado para cargas de trabalho complexas de saúde, o MongoDB Atlas substitui sistemas legados por um ecossistema de dados nativo e altamente otimizado. Abaixo está uma visão geral das funcionalidades principais que permitem que a plataforma forneça suporte à decisão em tempo real.

Figura 3. Principais funcionalidades do Atlas

Document model flexível: o patient_360 collection armazena um registro completo do paciente em um único documento, incluindo dados demográficos, condições, medicamentos, exames, resumos de sinais vitais, lacunas de cuidados, alertas, limites personalizados e proveniência de dados. Um único documento responde a perguntas que exigiriam junções de vários recursos em um armazenamento FHIR.

Coleções de séries temporais: A coleção synthetic_vitals armazena dados de dispositivos vestíveis usando as coleções de séries temporais nativas do MongoDB. Essas coleções fornecem agrupamento automático de dados, queries de faixa eficientes e armazenamento criado especificamente para dados de alta frequência e ordenados por tempo.

Fluxos de alteração: A plataforma usa fluxos de alteração para React a novos sinais vitais em tempo real. Quando uma leitura chega, o sistema avalia as regras do CDS e gera alertas clínicos sem pesquisa.

Queryable Encryption: O MongoDB Queryable Encryption protege os campos confidenciais do paciente em repouso. O aplicativo query campos criptografados PHI sem expor texto simples, atendendo aos requisitos da HIPAA e eliminando a necessidade de uma camada de criptografia separada.

Pipeline de agregação: este framework lida com agregações de dashboard, cálculo de lacunas de cuidado, análise de tendência de sinais vitais e pontuação HEDIS, resolvendo query clínicas complexas em milissegundos.

Estrutura para IA e análise: o documento patient_360 fornece fatos clínicos normalizados, evidências estruturadas e proveniência de metadados para pipelines de IA e análise downstream sem transformação adicional.

O pipeline de geração de dados

Após a inicialização, esta solução usa um pipeline de várias etapas para semear e ativar o sistema CDS, ilustrado abaixo.

Figura 4. Pipeline de geração de dados

O pipeline de geração de dados impulsiona a sequência de inicialização que cria dados clínicos sintéticos e materializados, calcula limites personalizados e lacunas de atendimento e inicia o monitoramento em tempo real. O pipeline funciona da seguinte forma:

1. Gera pacotes de pacientes FHIR: Cria pacotes de transações FHIR R4 incluindo condições, medicamentos, observações de laboratório, encontros e alergias. Ele armazena esses pacotes no armazenamento de dados FHIR, que serve como camada de interoperabilidade.

2. Gera históricos de sinais vitais: produz uma série temporal de 24horas de sinais vitais por paciente, representando padrões fisiológicos normais, deteriorados ou agudos. Ele armazena os dados na coleção de séries temporais synthetic_vitals.

3. Materializa documentos patient_360: transforma cada pacote FHIR em um documento patient_360 desnormalizado no MongoDB Atlas. A transformação inclui um bloco data_provenance que se vincula ao registro FHIR de origem.

4. Regras de CDS de sementes: Insere definições de regras de suporte à decisão clínica na coleção cds_rules.

5. Calcula limites personalizados: calcula limites de sinais vitais por paciente com base em medicamentos e condições ativas. Ele armazena esses resultados no documento patient_360.

6. Avalia as regras de CDS: Executa o AlertEngine em relação aos sinais vitais atuais e grava alertas gerados na coleção alerts.

7. Calcula lacunas de cuidados HEDIS: executa o QualityEngine em relação ao histórico clínico de cada paciente e grava os resultados estruturados da lacuna de cuidados no documento patient_360.

8. Atribuições do provedor de sementes: Gera relacionamentos de atribuição provedor-paciente na coleção attributions, determinando quais provedores recebem resultados e alertas de lacunas.

9. Inicia o monitoramento em tempo real: ativa o worker de simulação de sinais vitais e começa a fazer streaming de dados de sinais vitais ao vivo para a plataforma clínica por meio de eventos enviados pelo servidor.

O mecanismo CDS

Os mecanismos CDS analisam os dados do paciente para fornecer perspicácia acionável para as equipes de atendimento. Esta solução separa o monitoramento clínico do cálculo da medida de qualidade em dois mecanismos independentes. Este padrão arquitetônico adere à iniciativa Da Vinci, um programa acelerador HL7 FHIR para interoperabilidade de atendimento, que recomenda a dissociação de alertas em tempo real e lógica de lacunas HEDIS.

Fluxo de trabalho de lacunas de cuidados

O fluxo de trabalho de lacunas de cuidado serve como o processo sistemático que as organizações de saúde usam para identificar, acompanhar e resolver discrepâncias entre o cuidado clínico real de um paciente e as diretrizes médicas estabelecidas. A detecção de lacunas de cuidado segue um caminho estruturado da identificação ao fechamento, consistindo nestas ações:

• Avaliar: O QualityEngine avalia o histórico clínico de cada paciente em relação aos critérios de medida HEDIS.

• Gravar: O sistema grava lacunas abertas no documento patient_360, juntamente com suas evidências de suporte, ação recomendada e prioridade.

• Revisar: os coordenadores de cuidados revisam as lacunas abertas na plataforma clínica, classificadas por prioridade e período de atraso.

• Intervir: Para lacunas acionáveis, como KED e CDC-HBA, a plataforma abre um espaço de trabalho de intervenção estruturado onde o coordenador solicita laboratórios, registra a conclusão ou agenda o acompanhamento.

• Fechar: Quando a intervenção for concluída, o status da lacuna será atualizado no documento patient_360 e o QualityEngine será reavaliado no próximo ciclo.

• Escalar: quando o AlertEngine detecta um alerta clínico, ele eleva a prioridade das lacunas abertas relacionadas e notifica a equipe de atendimento. Alertas sem uma lacuna relacionada, como um aviso de sepse, são encaminhados diretamente para a equipe de atendimento como notificações clínicas independentes.

Dados clínicos como array de documentos

No documento patient_360, cada condição representa uma entrada no array conditions, enquanto cada medicação representa uma entrada no array medications. Conforme mostrado abaixo, o documento armazena entidades clínicas na forma como são usadas, em vez de dividir em tabelas separadas:

{
   "conditions": [
      {
         "code": "44054006",
         "display": "Type 2 diabetes mellitus",
         "clinical_status": "active",
         "onset_date": "2017-10-21T21:29:59.716351+00:00"
      },
      {
         "code": "433144002",
         "display": "Chronic kidney disease stage 3",
         "clinical_status": "active",
         "onset_date": "2023-09-12T21:29:59.716372+00:00"
      }
   ],
   "medications": [
      {
         "display": "Insulin glargine 100 units/mL injection",
         "dose": "20.0 units",
         "route": "subcutaneous",
         "frequency": "once daily at bedtime",
         "status": "active"
      },
      {
         "display": "Atenolol 50 mg oral tablet",
         "dose": "50.0 mg",
         "route": "oral",
         "frequency": "once daily",
         "status": "active"
      }
   ]
}

Campos operacionais computados

O pacote FHIR contém dados de interoperabilidade padrão, enquanto o documento patient_360 incorpora campos operacionais que o FHIR não define, incluindo sinalizadores clínicos, resultados de lacunas de atendimento, limites personalizados e alerta ativos.

Por exemplo, o pipeline de materialização, incorporado ao pipeline de geração de dados mais amplo, calcula sinalizadores clínicos do pacote FHIR e os grava diretamente no documento patient_360. O AlertEngine lê esses sinalizadores para determinar quais regras CDS se aplicam a um paciente, incluindo:

• flags.has_beta_blocker: Ativa a regra de frequência cardíaca do betabloqueador.

• flags.has_insulin: Ativa a regra de hipoglicemia multifatorial.

• flags.has_ckd: Ativa as regras de acidose metabólica e respiratória da DRC.

• flags.condition_codes: Códigos SNOMED para todas as condições ativas.

Os resultados da lacuna de cuidado usam a mesma abordagem. O pipeline de materialização calcula os resultados da lacuna de cuidado e os anexa diretamente ao documento patient_360. Cada medida HEDIS calculada é armazenada no array care_gaps junto com seus status, priority, evidence e recommended_action associados. Ao contrário do FHIR padrão, o document model armazena essas informações junto com o registro clínico do paciente. Um exemplo dessa estrutura é mostrado abaixo:

{
   "care_gaps": [
      {
         "hedis_measure": "CDC-HBA",
         "measure_name": "Comprehensive Diabetes Care — HbA1c Testing",
         "status": "open",
         "days_overdue": 34,
         "priority": "high",
         "evidence": {
            "found": ["HbA1c 5.13% (2025-10-07)"],
            "missing": []
         },
         "recommended_action": "Schedule or order an HbA1c follow-up"
      }
   ]
}

Essa abordagem oferece flexibilidade adicional; quando os requisitos clínicos mudam, você pode estender o documento. As novas regras do CDS gravam novos campos no mesmo documento sem afetar os existentes.

Rastreabilidade para o Registro de Origem

O documento patient_360 constitui uma visualização operacional derivada, não uma substituição para o registro FHIR. O pipeline de materialização produz esta visualização a partir dos recursos FHIR. Para auditar qualquer decisão clínica ou resultado de lacuna de cuidado, cada documento inclui um bloco data_provenance:

{
   "data_provenance": {
      "layer": "cds_operational",
      "source_fhir_collection": "synthetic_patients",
      "source_patient_id": "1b3bbaec-def8-4b55-8e87-9d04b55d6890",
      "materialization_version": "1.0",
      "last_materialized_at": "2026-05-09T21:30:04.873754+00:00",
      "fhir_resource_count": 22
   }
}

O armazenamento de dados FHIR permanece a fonte canônica da verdade para interoperabilidade, enquanto o MongoDB Atlas mantém a visão operacional, mantendo um link direto de volta aos seus dados de origem.

Campos criptografados no document model

Os regulamentos de assistência médica exigem que os aplicativos criptografem o PHI. Uma abordagem comum envolve armazenar o PHI criptografado em um sistema separado e recuperá-lo somente quando necessário. No entanto, esse framework introduz um segundo armazenamento de dados, uma camada separada de gerenciamento de chaves e maior latência para cada busca de registro do paciente.

O MongoDB Queryable Encryption elimina essa sobrecarga, mantendo o PHI no mesmo documento. Ele protege campos altamente confidenciais, como o nome do paciente, MRN e data de nascimento, tornando-os legíveis apenas para aplicativos cliente autorizados com a chave de criptografia. O restante do documento permanece consultável para uso operacional:

{
   "demographics": {
      "name": { "$binary": { "base64": "EAXZmoXjO0re...", "subType": "06" } },
      "given": { "$binary": { "base64": "EF1RChFVFEJC...", "subType": "06" } },
      "family": { "$binary": { "base64": "EK18iT8qVki8...", "subType": "06" } },
      "birth_date": { "$binary": { "base64": "EJOsqgLJPEjI...", "subType": "06" } },
      "gender": "female",
      "age": 77
   }
}

Por exemplo, microsserviços como o AlertEngine e o QualityEngine lêem sinalizadores, limites e campos de lacunas de cuidados, nenhum lê os campos demográficos criptografados.