A referenciação chegou à clínica. Falta saber quem ficou responsável por ela.

Uma rede de clínicas recebe pedidos de parceiros por canais diferentes. A unidade de Lisboa confirma a chegada de um documento; uma colaboradora no Porto tenta contactar o utente; outra equipa procura uma informação em falta. Quando alguém pergunta pelo ponto de situação, existe atividade em vários sistemas, mas nenhuma responsabilidade claramente visível.

Uma integração FHIR pode ajudar a organizar esta passagem de trabalho quando os sistemas envolvidos oferecem interfaces adequadas. O valor está em relacionar o pedido com as tarefas e os acontecimentos seguintes. O âmbito deste artigo é administrativo: acompanhar receção, documentação e marcação, mantendo as decisões clínicas com os profissionais responsáveis.

O pedido e a tarefa têm identidades diferentes

Uma referenciação representa uma solicitação de serviço. Telefonar ao utente para confirmar disponibilidade é uma atividade necessária para a tratar. Misturar as duas coisas num único estado torna difícil perceber se um pedido está resolvido ou se apenas terminou uma ação administrativa.

Na especificação FHIR R4 ServiceRequest, o recurso representa um pedido de serviço. A mesma documentação distingue esse pedido do acompanhamento da sua execução através de tarefas. Esta distinção é útil no desenho funcional, mesmo antes de discutir os campos de uma API.

Considere um contacto telefónico sem resposta. A tarefa pode terminar com esse resultado, enquanto o pedido continua aberto e exige uma nova ação. O painel deve mostrar o resultado da tentativa, a próxima responsabilidade e a relação com o pedido original. Uma indicação genérica de “concluído” esconderia a pendência.

Confirme o que cada fornecedor realmente suporta

Pedir uma integração “compatível com FHIR” ainda deixa decisões importantes em aberto. É necessário acordar a versão, os perfis utilizados, os recursos disponíveis, os identificadores e as operações permitidas. Uma interface que permite consultar pedidos pode não permitir criar tarefas ou atualizar marcações.

Solicite documentação e um ambiente de testes antes de fechar o orçamento. Registe também os limites de frequência, a forma de autenticação, as condições de acesso e a disponibilidade de eventos. A existência de uma norma não concede acesso automático a sistemas de terceiros ou a redes nacionais de saúde.

Use exemplos sintéticos para confirmar o contrato. O fornecedor deve demonstrar como representa um pedido corrigido, uma informação em falta e um cancelamento. Se alguma operação depende de exportação periódica ou intervenção humana, isso deve estar explícito. A equipa administrativa precisa de conhecer os intervalos em que o painel pode estar desatualizado.

Faça das pendências uma fila de trabalho utilizável

O recurso FHIR R4 Task permite representar uma atividade e acompanhar o seu estado, incluindo conclusão ou falha. Para uma clínica, isso pode apoiar uma fila com responsáveis, tentativas e motivos de bloqueio. O recurso técnico, porém, não define sozinho o processo da organização.

Desenhe uma pequena lista de tarefas compreensíveis: confirmar receção, esclarecer informação administrativa, contactar o utente e preparar a marcação. Cada tarefa deve ter uma entidade responsável e uma condição de conclusão observável. Evite criar dezenas de estados que a equipa não consegue distinguir durante o atendimento.

Quando uma tarefa muda de unidade, preserve o historial e confirme que existe alguém a recebê-la. Um pedido não deve desaparecer da fila porque um utilizador saiu da organização. As prioridades devem refletir as instruções dos profissionais autorizados; a integração não deve deduzir urgência clínica a partir de palavras encontradas num documento.

Identificadores estáveis evitam pessoas e pedidos duplicados

O mesmo pedido pode chegar duas vezes por repetição de uma transmissão. Também podem existir duas solicitações legítimas para a mesma pessoa. A integração precisa de distinguir esses casos sem assumir que nome, data ou endereço de correio eletrónico identificam tudo o que importa.

Defina a origem e o âmbito de cada identificador. Uma referência atribuída por um parceiro não tem necessariamente o mesmo significado noutro sistema. As regras de associação de pessoas devem ser aprovadas pela organização, com revisão humana quando existem dúvidas. Um algoritmo de semelhança não deve unir registos silenciosamente.

Separe ainda o acesso aos documentos do acesso à lista de tarefas. Uma equipa pode precisar de saber que falta um elemento administrativo sem poder consultar todo o processo. No primeiro projeto, documente perfis de acesso, registo de consultas, conservação e os campos que podem aparecer em notificações. Utilize dados sintéticos nas demonstrações e limite os dados operacionais ao necessário.

Peça uma demonstração com um percurso interrompido

Uma integração convincente deve mostrar mais do que a criação de um pedido. Prepare um conjunto pequeno de situações de aceitação:

• O mesmo pedido é recebido duas vezes sem gerar trabalho duplicado.
• Uma tarefa passa para outra unidade e mantém um responsável identificável.
• Um contacto sem resposta cria a pendência seguinte, sem concluir o pedido.
• Uma correção chega depois de a equipa começar o tratamento administrativo.
• Uma marcação é cancelada sem apagar o historial do pedido.
• Uma interrupção entre sistemas é recuperada sem produzir estados contraditórios.

Verifique também o que o utilizador vê durante a falha. O painel deve distinguir uma informação antiga de uma informação confirmada recentemente. Um indicador verde de disponibilidade do servidor pouco diz sobre pedidos que deixaram de chegar à unidade de destino.

Comece por um parceiro e uma passagem administrativa

Escolha um fluxo com volume e responsabilidade conhecidos, em vez de tentar substituir todos os sistemas da rede. O primeiro contrato pode cobrir a receção de pedidos de um parceiro e a distribuição das tarefas numa unidade. A expansão deve depender de resultados observáveis: menos pedidos sem responsável, menos contactos repetidos e menos tempo a procurar informação.

O orçamento deve separar análise das interfaces, configuração dos acessos, desenvolvimento, testes conjuntos e acompanhamento operacional. A manutenção precisa de um dono, porque os sistemas de origem podem mudar. Considere igualmente o custo de continuar com um conector existente, caso já cubra o processo de forma satisfatória.

Os nossos artigos sobre documentos recebidos e efetivamente revistos e dados confirmados em serviços digitais exploram problemas relacionados de passagem de informação. A Innovation T desenvolve integrações e portais de operação. Descreva o percurso administrativo e os sistemas envolvidos, sem enviar dados de utentes para avaliar uma primeira integração verificável.

Perguntas frequentes

Uma integração FHIR substitui o software clínico existente?

Não necessariamente. Pode ligar pedidos e tarefas entre sistemas que disponibilizem interfaces compatíveis. A versão FHIR, os perfis, os recursos e as permissões concretamente suportados precisam de ser confirmados com cada fornecedor.

Receber uma referenciação significa que a consulta está marcada?

Não. A receção do pedido, o trabalho administrativo, a marcação e a realização do atendimento são estados diferentes. A integração deve ligá-los sem tratar a conclusão de uma tarefa como prova de atendimento.

A integração pode decidir automaticamente a prioridade clínica?

O âmbito descrito é administrativo. Deve encaminhar a prioridade e as decisões atribuídas pelos profissionais responsáveis, sem as substituir por inferências automáticas ou regras técnicas não aprovadas.