Conduta

Este recurso é somente leitura. POST /fhir/resources/RequestGroup não é uma operação suportada — veja Cadastrar ou atualizar para o que acontece se você tentar. Para registrar uma conduta por integração, o caminho é a Condição — veja Como registrar uma conduta.

Um atendimento sem nenhuma conduta escrita produz o recurso mesmo assim — e nele o campo action não vem. Não é uma lista vazia: a chave some do JSON. Um cliente que faça resource.action.length quebra; trate a ausência do campo como “nenhuma conduta”.

A ausência não significa que o atendimento não existe: significa que ninguém escreveu conduta nele.

Condutas sem texto não entram na lista. Se a equipe abriu uma conduta e não escreveu nada, ela não aparece aqui, nem como item vazio — e um atendimento cujas condutas sejam todas vazias cai no caso acima, sem action.

Na tela, as condutas de um atendimento aparecem concatenadas num campo só, e o editor trabalha sobre a primeira delas. A separação em itens existe aqui e na Condição, não lá: um atendimento que a sua integração gravou com três condutas é visto pela equipe como um texto único.

status e intent são constantes e não informam nada sobre o atendimento nem sobre a conduta. status: active não quer dizer que o atendimento está aberto — quem diz isso é o status do atendimento. E intent: order não distingue tipos de conduta: todas saem iguais.

Ele tem a forma de uma referência FHIR, mas traz apenas display, com o valor constante Clinical conduct — em inglês, e igual em todos os itens. Não tente resolvê-lo, e não o use para classificar a conduta: ele não aponta para recurso nenhum e não carrega informação.

Um POST /fhir/resources/RequestGroup não é uma operação suportada e não devolve um erro de validação tratável: a chamada falha com erro inesperado do servidor (500). Não escreva tratamento em cima desse comportamento — ele não é contrato, e nada é gravado de qualquer forma.

Dentro de uma carga em lote o erro é limpo, e igualmente definitivo: a entrada é recusada com Resource RequestGroup not supported.

A conduta que você grava não aparece aqui na hora. Este recurso é produzido a partir do atendimento, e escrever uma conduta não regrava o atendimento. A conduta nova só entra em action[] na próxima vez que o atendimento em si for salvo.

Para ler de volta o que você acabou de gravar, leia a Condição — ela é atualizada na hora. Vale o mesmo para conduta acrescentada, editada ou removida pela equipe no Nilo Care sem tocar no atendimento.

Se você processa o texto da conduta, escolha um dos dois e fique com ele. Somar os dois duplica o conteúdo, e compará-los caractere a caractere não funciona — a divisão em linhas é justamente o que difere.

“O recurso próprio da conduta” não é sempre a Condição. Quem decide é o desfecho do atendimento: num atendimento de sugestão terapêutica a conduta sai como pedido de serviço, e num de resultado de exame sai como procedimento. Nos dois casos não existe Condition correspondente, e uma busca de condições por verification-status=provisional não encontra essas condutas.

O RequestGroup, esse, é sempre o mesmo, qualquer que seja o desfecho: uma entrada por conduta com texto, sem distinção de tipo. Se você precisa do inventário completo das condutas de um atendimento, é por aqui — não pela Condição.

Busca sem resultados não é erro: volta 200 com um Bundle cujo entry é uma lista vazia. Trate a ausência de resultados pela lista vazia, não esperando um 404.

Só a forma :identifier funciona neste recurso. As referências são gravadas sem o campo reference — só com identifier e type —, e a busca por referência sem o modificador procura justamente em reference. Por isso patient=Patient/{id}, subject=… e encounter=Encounter/{id} devolvem Bundle vazio, não erro. É a mesma situação da avaliação clínica.

Qual identificador o subject carrega é decidido referência a referência, não de uma vez por implantação. Na configuração que usa identificadores externos, cada referência sai com o identificador do seu sistema se o recurso apontado tiver um; se não tiver, cai silenciosamente no identificador Nilo. Confira o que veio na resposta antes de montar a busca em volume — vale para subject e para encounter.

O identifier do próprio recurso é a exceção: ele nunca depende da implantação e nunca é o seu. É sempre o identificador Nilo do atendimento de origem, no system …/NamingSystem/care-api--appointment-v3 — o mesmo valor que aparece nos identificadores do atendimento correspondente. Para chegar às condutas a partir da sua própria chave, o caminho é encounter:identifier, não identifier.

Recursos de atendimentos antigos podem trazer também um identificador no system …/NamingSystem/care-api--appointment, sem o -v3. É o mesmo atendimento.

Vários parâmetros canônicos do RequestGroup existem e não encontram nada aqui, porque a plataforma não preenche o campo correspondente: author, authored, code, group-identifier, instantiates-canonical, instantiates-uri, participant e priority.

Não há como buscar pelo texto de uma conduta: action[].description não tem parâmetro de busca no FHIR R4.

Diferente da busca, esta leitura não devolve um Bundle — mas também não devolve o recurso nu. A resposta é um envelope com fullUrl, search e resource, e as condutas estão em resource. Ler action na raiz da resposta não encontra nada.