Atendimentos e agendamento
Atendimento, evento e agendamento compartilham um traço que causa confusão: o mesmo recurso FHIR alimenta telas diferentes da plataforma, e o que decide qual é um campo do payload. Errar esse campo não produz um erro de validação — produz um recurso que foi aceito e foi para o lugar errado, ou um erro sobre um recurso referenciado que “não existe” quando ele existe.
Os fundamentos estão em Atendimentos, Hospitalização, Pronto atendimento e Agendamento.
Encounter does not exist e Unable to locate Nilo model for the resource
Causa. A Condition foi roteada para o fluxo errado. O campo category é o que decide:
Sem category, uma condição ligada a uma hospitalização é tratada como diagnóstico de
atendimento e vai procurar um atendimento comum — que não existe. Daí o Encounter does not exist sobre um Encounter que você acabou de criar com sucesso.
O que fazer. Sempre que a condição estiver associada a um evento de hospitalização ou pronto
atendimento, envie category com system e code de event. Veja
Condição.
Se você já enviou a condição sem category e o identificador ficou gravado no fluxo errado,
corrigir o payload e reenviar com o mesmo identificador tende a produzir um erro diferente,
não o sucesso — o identificador já está associado ao outro fluxo. Nesse caso, abra um chamado
com o identificador afetado.
period.end menor ou igual a period.start
Causa. O período do atendimento é validado: o fim não pode ser anterior nem igual ao início.
O que fazer. Confira o fuso e o formato das duas datas. Períodos de duração zero — início e
fim idênticos — também são recusados: se o atendimento não tem duração conhecida, envie só o
start.
O mesmo identificador de agendamento chegou em datas diferentes
Causa. Não é duplicidade. Um agendamento tem ciclo de vida: ele pode ser cancelado, reagendado e concluído, e cada mudança de status gera uma notificação — todas com o mesmo identificador, porque é o mesmo agendamento.
O que fazer. Trate a notificação como “o estado atual deste agendamento é este”, não como
“um novo agendamento chegou”. Antes de tratar como duplicidade, olhe o status de cada evento na
sequência: cancelled seguido de booked seguido de fulfilled é um reagendamento normal.
Cancelar um agendamento
Causa de confusão. Um agendamento cancelado não tem horário: ao cancelar, o início e o fim deixam de existir.
O que fazer. Envie status: cancelled sem start e sem end. Isso é válido, e o
cancelamento é aplicado.
Conflito de horário no agendamento
Causa. A plataforma bloqueia agendamentos sobrepostos por padrão.
O que fazer. Permitir sobreposição é uma configuração do care provider, não um campo do payload — não há campo nem extensão a enviar. Se a sua operação precisa de sobreposição, peça a configuração ao time de suporte.
O diagnóstico enviado não aparece no atendimento
Causa. Um diagnóstico só aparece na tela do paciente quando está associado ao atendimento ou evento a que pertence. Um diagnóstico enviado solto é gravado, mas não tem onde ser exibido.
O que fazer. Envie a condição referenciando o Encounter correspondente, com a category
certa para o tipo daquele atendimento — as duas coisas juntas, porque a category é o que define
qual atendimento a referência procura.
Etiquetas
Duas mensagens aparecem com frequência ao registrar etiquetas — veja Etiqueta para os campos.
does not allow changing tag_id or patient_id after creation
Causa. O identifier.value enviado pertence a uma etiqueta já vinculada a outro
paciente, ou a outra etiqueta do mesmo paciente. O vínculo entre etiqueta e paciente é fixo
depois de criado.
O que fazer. Use um identificador único por combinação de etiqueta e paciente. Não reaproveite o identificador de uma etiqueta ao aplicá-la a outro paciente.
Period is required to create inactive flags
Causa. Uma etiqueta criada já inativa precisa dizer em que período ela valeu — sem isso, ela seria um registro inativo sem vigência.
O que fazer. Envie o period junto. Se a etiqueta é ativa, o período é opcional.