Esta página explica como a Cloud Healthcare API suporta referências de recursos FHIR.
Vista geral
As referências de recursos FHIR são links direcionais de um recurso de origem para um recurso de destino. As referências de recursos FHIR podem ser usadas para associar recursos. Por exemplo, o tipo de recurso FHIR Observation
tem um campo subject
do tipo Reference, que pode ser usado para criar um link para um recurso Patient
como o assunto da observação.
As referências de recursos FHIR também podem ser circulares. Por exemplo, o tipo de recurso FHIR CarePlan
tem um campo replaces
que pode apontar para outro CarePlan
.
O elemento mais importante na estrutura de referência FHIR é reference.
Os outros elementos, como display
e identifier
, são mantidos tal como estão na Cloud Healthcare API.
Os formatos suportados de Reference.reference
na Cloud Healthcare API
incluem:
- Referência de recursos locais
- URI que começa por
urn:uuid
ouurn:oid
- URL externo completo
- Referência de fragmento
Referência de recurso local
As referências de recursos são definidas como
RESOURCE_TYPE/RESOURCE_ID
.
A API Cloud Healthcare também suporta a anteposição do nome completo da loja FHIR
antes de RESOURCE_TYPE/RESOURCE_ID
. Por
exemplo,
FHIR_STORE_NAME/RESOURCE_TYPE/RESOURCE_ID
.
Se usar este formato, o nome da loja tem de corresponder à loja FHIR do pedido.
Caso contrário, o pedido é rejeitado devido a referências não locais.
A opção de configuração da loja
FhirStore.disableReferentialIntegrity
controla a verificação da integridade referencial para a validação de referências locais, que
está ativada por predefinição. Para mais informações sobre a verificação da integridade referencial,
consulte
Integridade referencial da FHIR.
Referências com versões
A API Cloud Healthcare suporta referências a uma versão específica do recurso de destino. Para criar um link para uma versão específica do recurso de destino, use o formato
após o RESOURCE_ID/_history/VERSION_ID
] na
referência local.
Quando a verificação de integridade referencial está ativada, o servidor verifica se a versão do histórico existe no FHIR store. O método
Resource-purge
remove as versões do histórico, independentemente de serem referenciadas ou não.
Referências condicionais
Em alternativa à especificação explícita do ID do recurso de destino, o
executeBundle
aceita uma referência condicional
consulta de pesquisa para o recurso de destino que é resolvida para o ID do recurso de destino no momento do pedido. Por exemplo, Patient?identifier=abc
.
Se a consulta de pesquisa não for resolvida para um recurso de destino ou for resolvida para mais do que um recurso de destino, o servidor rejeita o pedido, independentemente de a verificação da integridade referencial estar ativada.
URI que começa por urn:uuid
ou urn:oid
Quando usar o método
executeBundle
com um pacote de transações, podem ser usadas referências de identificadores exclusivos universais (UUID) ou identificadores de objetos(OID) para resolver referências a outros recursos que estão a ser criados ou atualizados no mesmo pacote. Para mais informações, consulte o
guia de gestão de pacotes FHIR.
URL externo completo
Os URLs externos completos, como http://www.example.com/abc
, são armazenados sem alterações
no campo de referência. A Cloud Healthcare API não resolve o URL nem tenta validar a respetiva validade.
Quando o URL externo completo corresponde ao URL completo da loja FHIR do pedido, a referência é tratada como uma referência de recurso local.
Referência de fragmento
Uma referência de fragmento aponta para um recurso contido incorporado num recurso. Por exemplo, se um registo de observação mencionar um clínico geral, mas não existir um diretório de profissionais de saúde controlado, não é possível criar um recurso de profissional de saúde completo. O médico de clínica geral é um recurso contido no registo de observação. Os campos de referência num recurso podem apontar
para os recursos incorporados através do formulário #[INLINE_RESOURCE_ID]
.
No exemplo de FHIR R4 seguinte, p1
e p2
são IDs de recursos inline que são
referenciados como #p1
e #p2
:
{
"resourceType": "Observation",
"contained": [
{
"resourceType":"Patient",
"id": "p1",
"generalPractitioner": {"reference": "#p2"}
},
{
"resourceType":"Practitioner",
"id": "p2"
}
],
"status": "final",
"subject": {"reference": "#p1"},
"performer": [{"reference": "#p2"}]
}
O [INLINE_RESOURCE_ID]
tem de existir como um recurso contido no recurso, caso contrário, o servidor rejeita o pedido. O recurso contido só pode ser referenciado pelo respetivo contentor ou outros recursos contidos no mesmo contentor.