Unidade de cuidado
Uma unidade de cuidado é como a sua operação se divide dentro do Nilo Care: uma clínica, uma regional, uma frente de atendimento. Pacientes, profissionais e equipes de cuidado são todos alocados a uma unidade, e é ela que delimita quem enxerga quem — um profissional vinculado à Unidade Centro trabalha com os pacientes da Unidade Centro.
Na tela a unidade aparece como o campo Unidade de cuidado: no cadastro do paciente, na ficha dele e no cadastro das equipes de cuidado, sempre como uma escolha em lista.
No FHIR o recurso é o Organization. Esta
página é curta de propósito: a unidade tem um único dado gravável, o nome. O valor dela
está em ser referenciada — por
Paciente, Profissional e
Equipe de cuidado —, e é por isso que ela costuma ser a
primeira coisa que uma integração cadastra.
Campos
A coluna No Nilo Care traz o rótulo com que o dado aparece para a equipe; são rótulos, não caminhos de navegação.
A referência declara name como obrigatório porque é o único dado que a plataforma
guarda desta unidade. O Organization do FHIR R4, em si, não exige o nome — quem recusa o
payload sem nome é a plataforma, e por isso essa recusa tem uma forma diferente das outras:
vem como code: exception, sem expression. Veja Erros.
Campos que a Nilo não usa
O Organization canônico traz muito mais do que esta integração lê: type, address,
partOf, contact, endpoint, text e contained. Nenhum deles é lido, e por isso nenhum
aparece na referência do recurso.
A referência lista só os campos suportados e por isso rejeita os demais no seu validador,
mas a API em si não recusa quem os manda. O que acontece com eles é que ficam guardados no
recurso e voltam nas leituras seguintes — sem nunca terem significado nada para a plataforma, e
sem aparecer em lugar nenhum do Nilo Care. Um address enviado assim parece o endereço da
unidade, e não é. Omita-os.
Cadastrar ou atualizar
A resposta é o recurso gravado, sem envelope:
Guarde o id: é por ele que se faz a leitura direta. Ao lado do seu identifier, a resposta
traz o identificador Nilo da unidade, no system
…/NamingSystem/sorting-hat-api--care-unit — é esse valor que aparece nas referências dos
outros recursos quando a sua implantação não usa identificadores externos.
O mesmo POST cria e atualiza. Reenviando um identifier que já corresponde a uma unidade,
ela é renomeada:
Não há como desativar nem excluir uma unidade por esta API. O active da resposta é
sempre true, e enviá-lo como false não muda nada. Encerrar uma unidade é assunto do
Suporte.
Renomear é seguro: nenhum vínculo de paciente, profissional ou equipe é afetado. O que muda é o rótulo, em todos os lugares onde a unidade aparece.
Buscar
A resposta é sempre um Bundle do tipo searchset:
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.
Parâmetros de busca suportados
Os demais parâmetros canônicos do Organization existem e não encontram nada aqui,
porque a Nilo não preenche o campo correspondente: address e as suas variações,
type, partof e endpoint. A exceção é o campo que você mesmo tenha enviado: ele fica
no recurso e passa a ser encontrável — mais um motivo para omitir o que a plataforma não usa.
A busca sem filtro nenhum é a chamada mais útil deste recurso: as unidades de um ambiente são poucas, e listá-las é como se descobre o identificador para referenciar em outros recursos.
A paginação é por _count e _page_token; havendo página seguinte, o Bundle traz a URL
pronta em link.
A consulta não devolve só as unidades que você criou: as criadas ou alteradas dentro do Nilo
Care também aparecem. Elas trazem apenas o identificador Nilo, no system
…/NamingSystem/sorting-hat-api--care-unit; só as que vieram por integração trazem também a
sua chave. É por essa diferença que você separa umas das outras.
Uma unidade antiga, que ninguém tenha tocado desde que a sua integração começou, pode não aparecer na lista. Se você espera uma unidade e ela não vem, peça ao Suporte — a busca não é um inventário garantido do ambiente.
Adotar uma unidade que já existe
Para passar a referenciar pela sua chave uma unidade que já estava na plataforma, envie um
POST com os dois identificadores: o Nilo, que casa com a unidade existente, e o seu, que
fica gravado ao lado. A partir daí as duas chaves encontram a mesma unidade, e você não precisa
mais carregar o identificador Nilo.
Mande no name o nome que a unidade já tem — lembre que o name é sempre gravado, e um nome
diferente renomeia a unidade.
Ler por ID
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 unidade está em
resource. Ler name na raiz da resposta não encontra nada.
Valores devolvidos que não são da unidade
Dois campos da resposta enganam, e vale saber antes de construir tela em cima deles:
telecom é o telefone da sua operação, não o desta unidade. Todas as unidades do ambiente
devolvem o mesmo número — o cadastrado para o seu ambiente. Ele é omitido quando não há
telefone cadastrado. Não trate esse valor como contato da unidade.
E ao contrário dos campos não suportados, um telecom que você envie não sobrevive: ele é
substituído pelo telefone do ambiente na gravação. Não há como registrar um telefone próprio da
unidade por esta API.
alias repete o name. É sempre uma lista de um item, com o mesmo texto do nome, e
nunca traz um nome alternativo de verdade. Existe para quem lê o alias do Organization
canônico e não encontraria nada.
Onde a unidade é referenciada
Nos três casos a unidade precisa já existir, e é referenciada por identificador. Cadastre as unidades antes de cadastrar paciente, profissional ou equipe.
Qual identificador vale muda conforme o recurso. Paciente e Profissional aceitam qualquer
identificador da unidade, inclusive a sua chave — no Paciente, a referência precisa vir com
"type": "Organization" para a chave própria ser resolvida. A Equipe de cuidado é a exceção:
ela lê só o identificador Nilo da unidade, e um identificador do seu sistema é ignorado em
silêncio, caindo na unidade padrão.
Alguns desses campos caem numa unidade padrão da implantação quando você os omite. Isso é configuração do seu ambiente, não do recurso: se não houver unidade padrão configurada, a escrita do outro recurso é recusada. Veja a página de cada um.
Efeitos colaterais
Criar uma unidade não move ninguém para ela. A unidade nasce vazia; pacientes, profissionais e equipes só passam a pertencer a ela quando os recursos deles a referenciam.
Este endpoint nunca responde 204: não há remoção de unidade por integração.
Erros
Recusa é 400, e o corpo é um OperationOutcome: issue[].details.text explica o motivo e,
quando a recusa é de um campo conferido por esta API, issue[].expression aponta qual.
A última linha não é uma validação desta API — é a recusa da própria plataforma, repassada
como está. Ela sai com code: exception, sem expression, e com uma mensagem de erro de
linguagem em vez de uma explicação do campo. Não tente interpretar o texto: trate
code: exception como “payload recusado, motivo não classificado” e confira o name.
Os payloads completos estão na aba Referência, em POST /fhir/resources/Organization.

