Consultas FHIR no conector 2.9.3

A conclusão que orienta todo o uso

O código analisado comprova publicação FHIR, mas não comprova que os mesmos endereços ofereçam pesquisa FHIR.

Evidência	Conclusão segura
POST e PUT no código do conector	Os destinos configurados são comprovadamente usados para escrita
Ausência de GET FHIR no código	Não afirmar que o conector pesquisa recursos FHIR
GET de laudo no AGHU	Recuperação do PDF ocorre antes da montagem do Bundle e não prova leitura FHIR
Parâmetros de busca da especificação R4	São possibilidades que dependem do suporte declarado pelo servidor

Os modelos do conector usam estratégias diferentes conforme o conteúdo de origem.

Fluxo	Publicação observada	Recursos principais
Agendamento presencial ou teleconsulta	Atualização de recurso individual	Appointment
Resultado de exame	Bundle transacional em FHIR JSON	DiagnosticReport, ServiceRequest e Binary
RAC, RAC 4.2, Sumário de Alta e anexos	Bundle documental MHD em FHIR XML	Patient, Practitioner, DocumentManifest, DocumentReference e Binary
Paciente e profissional no fluxo cadastral	Mensageria PIX/HL7v3	Não corresponde a FHIR REST no envio primário
PDF do laudo	Leitura na API AGHU	Conteúdo convertido para o anexo do resultado

A descoberta deve acontecer antes de implementar consultas ou assumir parâmetros disponíveis.

1
Identificar o serviço correto
Confirmar com a infraestrutura qual base FHIR está destinada a consultas e em qual ambiente o teste é permitido.
2
Ler o CapabilityStatement
Consultar os metadados do servidor autenticado e verificar versão FHIR, formatos e recursos expostos.
3
Conferir interações
Validar read e search-type para cada recurso, sem inferir capacidade a partir de outro recurso.
4
Conferir parâmetros
Usar apenas searchParams declarados e confirmar modificadores, buscas encadeadas e _include.
5
Testar com dados controlados
Executar em ambiente autorizado, sem dados pessoais em logs, e registrar resposta, paginação e OperationOutcome.

Quando declarados pelo servidor, estes são os critérios mais úteis para os recursos produzidos.

Recurso	Critérios candidatos	Cuidados
Appointment	Identificador, paciente, período, status e tag organizacional	Atores contidos podem limitar pesquisas independentes
DiagnosticReport	Identificador, paciente, emissão, status, tag e solicitação	Categoria pode estar ausente na carga atual
ServiceRequest	Identificador, requisição, paciente, autoria, status e encounter	Distinguir solicitação inteira de item de exame
DocumentReference	Identificador, paciente, tipo, período, autor, MIME e status	O conteúdo clínico pode estar no Binary associado
DocumentManifest	Identificador, paciente, criação, origem, tipo e item	Confirmar suporte do servidor e versão do perfil MHD
Patient e Practitioner	ID físico ou identificador de negócio	Disponibilidade depende do processamento da plataforma

Algumas referências no payload parecem pesquisáveis, mas não representam recursos autônomos.

Recursos contidos não possuem URL REST independente e normalmente não podem ser pesquisados como instâncias autônomas.
Uma referência condicional em um Bundle é uma instrução de escrita; não prova que o conector executou uma consulta GET.
A presença de uma propriedade de configuração não comprova seu uso em uma chamada HTTP.
A classificação implícita de um perfil não garante o preenchimento do elemento de categoria pesquisável.
Identificadores devem ser tratados como dados controlados; exemplos reais não pertencem ao portal público.