O fluxo real de transformação

O SCM funciona como camada intermediária entre a origem relacional e os formatos publicados.

AGHU / SQL
    │
    ▼
Extrator Java ──→ SCM (agent.model) ──→ XSLT ──→ Recurso ou Bundle FHIR
                                      │
                                      └──→ documento openEHR + MHD, conforme o fluxo
  1. 1
    Extrair

    Consultas SQL e integrações complementares recuperam dados do AGHU para um extrator específico.

  2. 2
    Modelar

    O extrator popula classes SCM que desacoplam o formato relacional da transformação final.

  3. 3
    Transformar

    XSLTs convertem o modelo intermediário em recurso FHIR, documento clínico ou Bundle transacional.

  4. 4
    Publicar

    O cliente envia o artefato ao serviço correspondente com autenticação e contexto do conector.

  5. 5
    Rastrear

    A sustentação relaciona campo de origem, propriedade SCM, transformação e elemento final sem saltar etapas.

Modelos e saídas atuais

A presença de uma classe não significa que todas as suas propriedades tenham origem implementada ou destino publicado.

ModeloOrigem/fluxoSaída observada
AGDModelAgendamento presencial e teleconsultaAppointment individual
AttachmentModelDocumentos assinados e anexosBundle MHD com DocumentReference e Binary
ResultadoExameModelResultados armazenados e interfaceadosBundle com DiagnosticReport, ServiceRequest e Binary
RAC42ModelRegistro de Atendimento Clínico 4.2Documento openEHR transportado em Bundle MHD
RACModelEstrutura RAC 4.1Modelo e transformação presentes, sem origem SQL concreta no recorte
SAModelSumário de AltaDocumento openEHR e metadados de período em MHD
PatientModel e PractitionerModelIdentidade compartilhadaFluxo cadastral PIX/HL7v3 e referências nos documentos

Produção atual versus equivalência candidata

O de-para separa o que existe no pipeline do que seria uma evolução possível em FHIR granular.

Conteúdo clínicoRepresentação atualEquivalência candidata
Atendimento e internaçãoMetadados e documento clínicoEncounter
DiagnósticosConteúdo do RAC ou Sumário de AltaCondition e Encounter.diagnosis
AlergiasConteúdo documentalAllergyIntolerance
Sinais e mediçõesConteúdo documentalObservation
ProcedimentosConteúdo documentalProcedure
PrescriçõesTexto agregadoMedicationRequest com dose estruturada
Plano e recomendaçõesSeções do documentoCarePlan, ServiceRequest ou Composition

Lacunas e decisões registradas

A atualização transforma achados do código em uma agenda objetiva de engenharia.

  • Definir se RAC e Sumário de Alta continuarão apenas documentais ou também terão recursos clínicos granulares.
  • Implementar uma origem concreta para RAC 4.1 ou retirar o modelo da matriz de extração ativa.
  • Corrigir o relacionamento da codificação alternativa de exames entre o modelo, o SQL e a transformação.
  • Popular a categoria do resultado de exame de forma coerente com perfil e pesquisa FHIR.
  • Revisar a semântica de criação e atualização do Appointment.
  • Definir destino para campos de agendamento extraídos e atualmente descartados.
  • Estruturar medicamento, dose, via, frequência, duração e status antes de produzir MedicationRequest confiável.
  • Validar a versão MHD exigida pelo receptor antes de alterar o contrato atual.

Como usar a rastreabilidade na sustentação

O de-para reduz diagnósticos baseados apenas no payload final.

  1. 1
    Localizar o fluxo

    Identificar o extrator e o tipo de documento ou recurso afetado.

  2. 2
    Conferir a origem

    Validar se o campo existe no SQL ou na integração complementar da versão analisada.

  3. 3
    Conferir o SCM

    Verificar preenchimento, nulidade e relação entre as classes do modelo intermediário.

  4. 4
    Conferir o XSLT

    Confirmar condição, caminho e elemento de destino na transformação.

  5. 5
    Conferir a publicação

    Distinguir falha de transformação, Bundle, endpoint, perfil ou persistência.