Conector e adaptador resolvem movimentos diferentes

A sessão de 2 de outubro começa pela direção da busca para explicar duas estratégias de integração com sistemas que não oferecem FHIR nativamente.

AspectoConectorAdaptador
IniciativaAgente próximo à origem busca, processa e enviaA plataforma consulta ou media a origem quando precisa
DistribuiçãoPode existir por hospital, sistema, modelo ou cargaTende a residir na camada de integração central
Tecnologia mostradaAplicação Java/Spring com extratores e modelosMediação no ecossistema WSO2
Escala operacionalAdequado a múltiplas origens heterogêneasÚtil para acesso centralizado e integração sob demanda
ObservabilidadeEstado, progresso, lotes, respostas e logs própriosChamadas, políticas, mediações e logs da plataforma

Extrator e modelo desacoplam origem e saída

O desenho demonstrado separa como o dado é lido de como o artefato interoperável é produzido.

Banco de origem
  ↓ consultas por janela
Arquivos intermediários por classe
  ↓ correlação pelo registro principal
Documento lógico de um atendimento
  ↓ transformação + validação
OpenEHR / recurso ou documento FHIR
  ↓ envelope, autenticação e envio
HU Digital
  ↓ resposta validada
Estado + auditoria + próxima janela

No caso apresentado, várias consultas retornam partes administrativas e clínicas. O conector percorre os relacionamentos e reúne as linhas pertencentes ao mesmo registro antes de transformar o conteúdo. Essa etapa evita misturar dados de atendimentos diferentes.

Transformações e validações variam por modelo. RAC e Sumário de Alta preservam templates openEHR e depois são envelopados para a transação de documentos; outros casos produzem recursos FHIR ou anexos com regras próprias.

Cada fluxo mantém seu próprio avanço

O conector precisa continuar cargas periódicas, retomar após reinício e impedir que a falha de um modelo paralise todos os demais.

  1. 1
    Definir a janela

    Datas mínima e máxima delimitam o lote de cada modelo e evitam reler toda a origem.

  2. 2
    Extrair

    Consultas materializam apenas os registros candidatos daquela janela.

  3. 3
    Processar por documento

    O agrupamento separa cada atendimento ou resultado antes da transformação.

  4. 4
    Enviar e validar

    A resposta é classificada segundo o contrato do modelo; sucesso técnico e aceitação clínica não são confundidos.

  5. 5
    Persistir o avanço

    O estado por modelo é salvo para que reinícios retomem do ponto controlado.

  6. 6
    Publicar progresso

    Auditoria e métricas permitem comparar o que foi lido, enviado, aceito e rejeitado.

ModoObjetivoRisco a controlar
Tempo real/periódicoAvançar continuamente sobre novos registrosAtraso silencioso e janela presa em erro
Carga históricaProcessar intervalo passado até uma data de corteDuplicação, versão incorreta e competição por recursos
ReprocessamentoReenviar o que foi corrigido ou evoluiu de versãoSobrescrever versão mais nova ou repetir efeito
Instância dedicadaIsolar fluxo de alto volumeDivergência de configuração e observabilidade fragmentada

Cinco famílias de informação demonstradas

O repasse compara modelos nacionais mais formais com casos institucionais construídos sobre recursos FHIR e anexos.

FamíliaRepresentação apresentadaParticularidade operacional
RACDocumento clínico estruturado em openEHR, transportado no fluxo documentalGrande volume ambulatorial e muitas classes correlacionadas
Sumário de AltaTemplate openEHR e envelope documentalResumo da alta, não reprodução integral da internação
Documentos assinadosDocumentReference e conteúdo HTML/PDF como anexoAutoria, tipo e versão orientam consulta e reprocessamento
Agendamentos/teleconsultaModelo institucional progressivamente alinhado a AppointmentDados de sala, vínculo e evento podem vir de fontes diferentes
Resultados de examesDiagnosticReport, ServiceRequest, códigos e laudo anexoLiberação parcial, vocabulários locais e obtenção complementar do PDF

A separação entre cadastro demográfico e conteúdo clínico aparece como controle de redução de exposição: o documento usa uma referência de paciente e a correlação identificável fica no serviço de identidade clínica.

Em exames, o workshop mostra a coexistência de códigos locais, SIGTAP e LOINC. Preservar códigos disponíveis pode apoiar conciliação futura, mas não transforma automaticamente terminologias diferentes em equivalentes.

Triagem orientada por etapa

Uma falha do conector deve ser localizada antes de qualquer reprocessamento.

EtapaEvidência mínimaPergunta de diagnóstico
SeleçãoJanela, contagem e chave técnicaO registro era elegível e estava no intervalo?
ExtraçãoResultado de cada classe e ausência de erro de conexãoA origem retornou todas as partes obrigatórias?
CorrelaçãoQuantidade de documentos lógicos produzidosLinhas do mesmo registro foram reunidas corretamente?
TransformaçãoVersão do modelo e validação estruturalO conteúdo respeita cardinalidade, tipo e terminologia?
IdentidadeResultado mascarado da correlação no MPIO paciente correto foi resolvido sem ambiguidade?
EnvioStatus, categoria de resposta e tempoA autenticação e o contrato aceitaram a requisição?
EstadoÚltimo avanço confirmado por modeloÉ seguro avançar, repetir ou isolar o item?
AuditoriaEvento no índice e métrica correspondenteA visão operacional concorda com o backend receptor?

Capítulos para revisão dirigida

Abra as quatro gravações pelo Guia do repasse e use os timestamps abaixo.

SessãoTimestampAssunto
02/1000:02:48Conector versus adaptador
02/1000:49:58Abstração extrator + modelo
02/1001:20:47Extrator PostgreSQL do AGHU
03/1000:21:51Anonimização e depuração
03/1001:11:01Validação openEHR
03/1002:28:30Pipeline do Sumário de Alta
09/1000:13:35Modelo de anexo reutilizado
09/1001:02:37Conectores de agendamento
10/1000:30:56DiagnosticReport e transformação
10/1001:08:27Pipeline e regras de carga
10/1001:45:01Complementação do laudo pela API