Paciente-tudo no FHIR

  • Artigo

A operação Patient-everything é utilizada para fornecer uma vista de todos os recursos relacionados com um paciente. Esta operação pode ser útil para dar acesso aos pacientes a todo o registo ou a um fornecedor ou outro utilizador para efetuar uma transferência de dados em massa relacionada com um paciente. De acordo com a especificação FHIR, Patient-everything devolve todas as informações relacionadas com um ou mais pacientes descritos no recurso ou contexto no qual esta operação é invocada. Na API do Azure para FHIR, o Patient-everything está disponível para extrair dados relacionados com um paciente específico.

Utilizar Patient-everything

Para chamar Patient-everything, utilize o seguinte comando:

GET {FHIRURL}/Patient/{ID}/$everything

Nota

Tem de especificar um ID para um paciente específico. Se precisar de todos os dados para todos os pacientes, consulte $export.

A API do Azure para FHIR valida que pode encontrar o paciente que corresponde ao ID do paciente fornecido. Se for encontrado um resultado, a resposta será um grupo de tipos searchset com as seguintes informações:

  • Recurso do paciente
  • Recursos que são referenciados diretamente pelo recurso do paciente, exceto referências de ligação que não são de seealso ou se a seealso ligação referencia um RelatedPerson.
  • Se existirem seealso referências de ligação para outros pacientes, os resultados incluirão a operação Patient-everything em relação aos seealso pacientes listados.
  • Recursos no Compartimento do Paciente
  • Recursos do dispositivo que referenciam o recurso do paciente.

Nota

Se o paciente tiver mais de 100 dispositivos ligados, apenas 100 serão devolvidos.

Parâmetros patient-everything

A API do Azure para FHIR suporta os seguintes parâmetros de consulta. Todos estes parâmetros são opcionais:

Parâmetro de consulta Descrição
_type Permite-lhe especificar que tipos de recursos serão incluídos na resposta. Por exemplo, _type=Encontro devolveria apenas Encounter recursos associados ao paciente.
_since Devolverá apenas os recursos que foram modificados desde a hora fornecida.
iniciar Especificar a data de início irá solicitar recursos onde a data clínica se encontra após a data de início especificada. Se não for fornecida nenhuma data de início, todos os registos antes da data de fim estão no âmbito.
fim Especificar a data de fim irá solicitar recursos onde a data clínica está antes da data de fim especificada. Se não for fornecida nenhuma data de fim, todos os registos após a data de início estão no âmbito.

Nota

Esta implementação de Patient-everything não suporta o parâmetro _count.

Num recurso do paciente, existe um elemento chamado ligação, que liga um paciente a outros pacientes ou pessoas relacionadas. Estes pacientes ligados ajudam a dar uma visão holística do paciente original. A referência de ligação pode ser utilizada quando um paciente está a substituir outro paciente ou quando dois recursos do paciente têm informações complementares. Um caso de utilização para ligações é quando é apresentada uma mensagem do ADT 38 ou 39 HL7v2. O ADT38/39 descreve uma atualização para um paciente. Esta atualização pode ser armazenada como uma referência entre dois pacientes no elemento de ligação.

A especificação FHIR tem uma descrição geral detalhada dos diferentes tipos de ligações de pacientes, mas eis um resumo de alto nível:

  • substitui - O recurso Paciente substitui um Paciente diferente.
  • veja - O paciente é válido, mas não é considerado a principal origem de informações. Aponta para outro paciente para obter informações adicionais.
  • seealso - O paciente contém uma ligação para outro paciente que é igualmente válido.
  • replaceed-by - O recurso Paciente substitui um Paciente diferente.

A operação Patient-everything na API do Azure para FHIR processa ligações de pacientes de diferentes formas para lhe dar a vista mais holística do paciente.

Nota

Uma ligação também pode referenciar um RelatedPerson. Neste momento, RelatedPerson os recursos não são processados em Patient-everything e não são devolvidos no pacote.

Neste momento, as ligações de substituição e referência são ignoradas pela operação Patient-everything e o paciente ligado não é devolvido no pacote.

Conforme descrito, as ligações seealso referenciam outro paciente que é considerado igualmente válido para o original. Após a execução da operação Patient-everything, se o paciente tiver seealso ligações para outros pacientes, a operação executa Patient-everything em cada seealso ligação. Isto significa que se um paciente ligar a outros cinco pacientes com uma ligação de tipo seealso , executaremos Patient-everything em cada um desses cinco pacientes.

Nota

Esta ação está configurada para seguir seealso apenas ligações com uma camada de profundidade. Não processa as ligações de seealso uma seealso ligação.

Veja também o diagrama de fluxo.

O tipo de ligação final é substituído por. Neste caso, o recurso original do paciente já não está a ser utilizado e a replaced-by ligação aponta para o paciente que deve ser utilizado. Esta implementação de Patient-everything incluirá, por predefinição, um resultado de operação no início do pacote com um aviso de que o paciente já não é válido. Este também será o comportamento quando o Prefer cabeçalho estiver definido como handling=lenient.

Além disso, pode definir o Prefer cabeçalho para handling=strict emitir um erro. Neste caso, uma devolução do código de erro 301 MovedPermanently indica que o paciente atual está desatualizado e devolve o ID do paciente correto incluído na ligação. O ContentLocation cabeçalho do erro devolvido irá apontar para o pedido correto e atualizado.

Nota

Se estiver presente Prefer: handling=lenient uma replaced-by ligação e os resultados forem devolvidos de forma assíncrona em vários pacotes, apenas um resultado da operação é devolvido num único pacote.

Ordem de resposta paciente-tudo

A operação Patient-everything devolve resultados em fases:

  1. A fase 1 devolve o Patient recurso em si, além de quaisquer generalPractitioner referências e managingOrganization recursos do IR.
  2. As fases 2 e 3 devolvem os recursos no compartimento do paciente. Se os parâmetros de consulta de início ou de fim forem especificados, a Fase 2 devolve recursos do compartimento que podem ser filtrados pela data clínica e a Fase 3 devolve recursos do compartimento que não podem ser filtrados pela respetiva data clínica. Se nenhum destes parâmetros for especificado, a Fase 2 é ignorada e a Fase 3 devolve todos os recursos do compartimento do paciente.
  3. A fase 4 devolverá todos os dispositivos que referenciam o paciente.

Cada fase devolverá resultados num pacote. Se os resultados abrangem várias páginas, a próxima ligação no pacote irá apontar para a página seguinte dos resultados dessa fase. Depois de todos os resultados de uma fase serem devolvidos, a ligação seguinte no pacote irá apontar para a chamada para iniciar a fase seguinte.

Se o paciente original tiver ligações seealso , as fases 1 a 4 serão repetidas para cada um desses pacientes.

Exemplos de Patient-everything

Eis alguns exemplos de utilização da operação Patient-everything. Além dos exemplos, temos um ficheiro REST de exemplo que ilustra como o seealso comportamento e replaced-by funciona.

Para utilizar o Patient-everything para consultar entre 2010 e 2020, utilize a seguinte chamada:

GET {FHIRURL}/Patient/{ID}/$everything?start=2010&end=2020

Para utilizar $patient-tudo para consultar a Observação e o Encontro de um paciente, utilize a seguinte chamada:

GET {FHIRURL}/Patient/{ID}/$everything?_type=Observation,Encounter

Para utilizar $patient tudo para consultar "tudo" de um paciente desde 2021-05-27T05:00:00Z, utilize a seguinte chamada:

GET {FHIRURL}/Patient/{ID}/$everything?_since=2021-05-27T05:00:00Z

Se for encontrado um paciente para cada uma destas chamadas, receberá uma resposta de 200 com um Bundle dos recursos correspondentes.

Passos seguintes

Agora que sabe como utilizar a operação Patient-everything, pode saber mais sobre as opções de pesquisa.

Descrição geral da pesquisa na API do Azure para FHIR

FHIR® é uma marca registada do HL7 e é utilizada com a permissão de HL7.