Avaliação clínica

Este recurso é somente leitura. Não existe POST /fhir/resources/ClinicalImpression — a avaliação clínica só é escrita pela equipe dentro do NiloCare. Veja O que a integração não cobre para o que acontece se você tentar enviá-la mesmo assim.

Apagar o texto no NiloCare não limpa o campo aqui. Quando o profissional esvazia a entrevista clínica, ou o atendimento perde o responsável, a avaliação continua devolvendo description e assessor com o valor anterior — a atualização preserva o que já estava gravado em vez de apagá-lo. Não conclua de um description presente que o texto ainda está lá no prontuário.

investigation e note[] não têm esse problema: quando o exame físico ou os pontos de atenção são removidos, eles somem da leitura.

status é constante e não serve para saber se o atendimento está aberto ou encerrado. Quem diz isso é o status do atendimento.

effectiveDateTime também não é o horário do atendimento: é a data de criação do registro. O período em que o atendimento aconteceu está em Encounter.period.

No registro de atendimento novo, os dois campos viraram um único texto na tela, e é description que recebe tudo o que o profissional escreve — entrevista e exame físico juntos. investigation deixa de ser alimentado e passa a guardar apenas o que já estava lá.

Duas consequências para quem lê:

• Não trate investigation como “o exame físico” e description como “a entrevista”. Onde o registro novo está em uso, description é a nota clínica inteira e investigation pode vir vazio mesmo havendo exame físico registrado.
• Num atendimento escrito antes da mudança e editado depois, o texto do exame físico aparece nos dois campos: ele é levado para dentro da nota, e o campo antigo é preservado como estava. Concatenar description com investigation duplica esse trecho.

As duas telas convivem hoje, e qual delas a equipe usa varia por implantação — o mesmo cliente pode ler recursos das duas formas na mesma busca. Se você processa o texto, leia description como a nota clínica e use investigation só como complemento, deduplicando.

note[].authorReference é sempre o profissional responsável pelo atendimento, o mesmo que está em assessor — não o autor daquele ponto de atenção. Um ponto anotado por outro profissional volta atribuído ao responsável. Não use esse campo para auditar quem escreveu o quê. note[].time nunca vem preenchido.

Só entram os pontos de atenção vinculados a este atendimento. O cartão de pontos de atenção que a equipe vê é do paciente, não do atendimento: ele mostra também os pontos de outros atendimentos e os que não pertencem a atendimento nenhum. Nenhum desses aparece aqui, nem em outro recurso desta API — a lista de note[] é sempre menor do que a da tela.

A lista é uma fotografia do momento em que o atendimento foi gravado. Acrescentar, editar ou remover um ponto de atenção sem tocar no atendimento não atualiza a avaliação clínica: a mudança só aparece na próxima vez que o atendimento em si for salvo.

Ela também desaparece por lá: apagado o atendimento no NiloCare, a avaliação clínica dele é removida, e um id que você já leu com sucesso passa a responder 404 sem aviso nenhum. Se você guarda o conteúdo, guarde o conteúdo — não o id.

Um POST /fhir/resources/ClinicalImpression 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 no NiloCare de qualquer forma.

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

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 da avaliação clínica 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=…, encounter=Encounter/{id} e assessor=Practitioner/{id} devolvem Bundle vazio, não erro. São exceção este recurso e a Conduta, que nasce do mesmo atendimento: em Atendimentos e Condição as duas formas funcionam.

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. Na mesma resposta, o subject pode vir com o seu system e o assessor com o da Nilo (…/NamingSystem/almanac-api--professional). Confira o que veio na resposta antes de montar a busca em volume — vale para subject, encounter e assessor.

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 Encounter correspondente. Para chegar à avaliação a partir da sua própria chave, o caminho é encounter:identifier, não identifier.

Avaliações de atendimentos antigos podem trazer também um identificador no system …/NamingSystem/care-api--appointment, sem o -v3. É o mesmo atendimento: o system antigo é preservado para não partir o histórico dos registros anteriores.

Vários parâmetros canônicos da ClinicalImpression existem e não encontram nada aqui, porque a plataforma não preenche o campo correspondente: finding-code, finding-ref, previous, problem, supporting-info e investigation.

investigation merece o aviso explícito: o campo existe e vem preenchido, mas o parâmetro canônico procura por referência dentro de investigation.item, e o item da Nilo carrega só texto em display. Não há como buscar pelo conteúdo do exame físico.

date é o outro caso: o parâmetro canônico procura em ClinicalImpression.date, e a plataforma preenche effectiveDateTime. Para recortar por período, use _lastUpdated — ou busque os atendimentos do período em Atendimentos e leia a avaliação de cada um por encounter:identifier.

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 a avaliação está em resource. Ler description ou identifier na raiz da resposta não encontra nada.

investigation[0].item[0] tem a forma de uma referência FHIR, mas não é uma: traz apenas display, com o texto do exame físico. Não tente resolvê-la.

O encounter nem sempre aponta para um atendimento do prontuário. Um atendimento classificado como pronto atendimento gera avaliação clínica do mesmo jeito, e a referência dela leva a um recurso que a busca de Atendimentos não devolve — ele está em Pronto atendimento.