Os FHIR stores na Cloud Healthcare API suportam várias versões da especificação Fast Healthcare Interoperability Resources (FHIR) publicada pela Health Level 7 International (HL7).
A API v1 suporta as seguintes versões:
- Versão R5 5.0.0 (Release 5)
- R4 versão 4.0.1 (Release 4)
- STU3 versão 3.0.1 (Release 3 – Standard for Trial Use)
- DSTU2 versão 1.0.2 (Norma provisória para utilização experimental)
Quando cria uma FHIR store, especifica a versão FHIR como um parâmetro para o método fhirStores.create
. Não pode alterar a versão da FHIR depois de criar a loja.
A interface da API para cada loja está em conformidade com a versão FHIR dessa loja. Por exemplo, a interação conformance
DSTU2 é diferente da interação capabilities
STU3, mas ambas partilham o caminho REST /fhir/metadata
, pelo que esse caminho devolve respostas diferentes com base na versão FHIR da loja.
A funcionalidade adicionada em versões FHIR posteriores está disponível em lojas que usam versões FHIR anteriores se não criar incompatibilidade. Por exemplo, a patch
interação está disponível numa loja DSTU2, mesmo que essa interação só esteja
definida a partir do STU3.
Detalhes da funcionalidade suportada na API v1 por versão FHIR
R5
A declaração de capacidade do servidor indica as partes da especificação que são suportadas.
- Armazenamento e obtenção de todos os recursos R5, incluindo suporte para elementos de extensão. A API aceita, armazena e devolve extensões em qualquer elemento de dados.
- Todos os métodos na
API RESTful
que usam o tipo de conteúdo JSON são suportados, exceto:
- As interações de histórico ao nível do tipo e do sistema que obtêm o histórico em vários recursos não são suportadas. Só é possível obter o histórico de recursos de um recurso de cada vez.
- A interação batch/transaction não suporta operações de pesquisa no pacote.
- A validação e a aplicação do perfil são suportadas.
- Os parâmetros de pesquisa definidos pelo utilizador, incluindo pesquisas em elementos de extensão, são suportados na API v1beta1.
Toda a funcionalidade de pesquisa é suportada, exceto:
- Os parâmetros de pesquisa
Group-characteristic-value
,Location-near
,Location-contains
,DocumentReference-relationship
,Bundle-composition
,Bundle-message
,Observation-component-value-canonical
,Observation-value-canonical
,QuestionnaireResponse-item-subject
eComposition-section-text
não são suportados. - Os parâmetros de pesquisa que fazem correspondência fonética não são suportados.
- Os parâmetros de resultados da pesquisa
_contained
,_containedType
,_summary=count
e_summary=true
não são suportados. - O parâmetro de pesquisa especial
_content
pesquisa todos os campos do recurso ao qual os parâmetros de pesquisa se referem. Exclui campos que não são pesquisáveis. Não suportaAND
explícito (os termos são combinados implicitamente comAND
) nem parênteses. - Os parâmetros de pesquisa especiais
Resource-query
,Resource-filter
,Resource-language
,Resource-in
eResource-list
não são suportados. - O parâmetro
_sort
, quando usado em campos com elementos repetidos, ordena pelo primeiro elemento. Isto difere da especificação._sort
é suportado para parâmetros de pesquisa do tiponumber
,data
,string
,token
equantity
. - O modificador de pesquisa de tokens
:of-type
,:code-text
,text-advanced
e:text
, e o modificador de pesquisa de referência:identifier
,not-in
,text-advanced
e:code-text
não são suportados. O modificadorcontains
para pesquisas de URI não é suportado. - As pesquisas de referências canónicas não são suportadas. As referências canónicas são tratadas como referências normais. Os modificadores
above
ebelow
não são suportados. - Quando usar o parâmetro
_type
, só pode usar os parâmetros de pesquisa comuns (a todos os recursos) e não a interseção dos tipos de recursos especificados. É suportado o seguinte subconjunto de parâmetros de pesquisa compostos:
Observation-code-value-concept
Observation-code-value-date
Observation-code-value-quantity
Observation-code-value-string
Observation-combo-code-value-concept
Observation-combo-code-value-quantity
Observation-component-code-value-concept
Observation-component-code-value-quantity
Os restantes parâmetros de pesquisa compostos não são suportados.
A pesquisa através do método
POST
não aceita parâmetrosapplication/x-www-form-urlencoded
no corpo do pedido.O caráter universal (
*
) é suportado para_include
, mas não é suportado para_revinclude
.
- Os parâmetros de pesquisa
As áreas não suportadas incluem:
- O tipo de conteúdo XML não é suportado.
- A operação de aplicação de patch não suporta o patch XML nem o patch
FHIRPath
. - Os pedidos HTTP HEAD não são suportados.
Determinados aspetos da API desviaram-se da especificação FHIR devido à retrocompatibilidade em versões FHIR anteriores. Estes problemas foram corrigidos na versão R5:
- Quando a validação de campos obrigatórios está ativada, os campos
null
e os campos vazios (por exemplo,{}
) são agora rejeitados. - O formato UpperCamelCase já não é suportado para campos de recursos em JSON.
- As referências
urn:uuid
não são permitidas em pacotes em lote, quer a integridade referencial esteja ou não desativada. Os pacotes em lote nunca reescrevem referências. - Os conjuntos de transações são mais rigorosos na reescrita de referências do que antes e geram erros em FullUrls inválidos nas entradas, conforme definido pela especificação: https://www.hl7.org/fhir/bundle.html#references.
- As referências que se assemelham a referências de recursos têm de ter IDs válidos.
- A validação do perfil base está ativada para pedidos PATCH.
R4
A declaração de capacidade do servidor indica as partes da especificação que são suportadas.
- Armazenamento e obtenção de todos os recursos R4, incluindo suporte para elementos de extensão. A API aceita, armazena e devolve extensões em qualquer elemento de dados.
- Todos os métodos na
API RESTful
que usam o tipo de conteúdo JSON são suportados, exceto:
- As interações de histórico ao nível do tipo e do sistema que obtêm o histórico em vários recursos não são suportadas. Só é possível obter o histórico de recursos de um recurso de cada vez.
- A interação batch/transaction não suporta operações de pesquisa no pacote.
- A validação e a aplicação do perfil são suportadas.
- Os parâmetros de pesquisa definidos pelo utilizador, incluindo pesquisas em elementos de extensão, são suportados na API v1beta1.
Toda a funcionalidade de pesquisa é suportada, exceto:
- Os parâmetros de pesquisa
Group-characteristic-value
,Location-near
,Bundle-composition
eBundle-message
não são suportados. - Os parâmetros de pesquisa que fazem correspondência fonética não são suportados.
- Os parâmetros de resultados da pesquisa
_contained
,_containedType
,_summary=count
e_summary=true
não são suportados. - O parâmetro de pesquisa especial
_content
pesquisa todos os campos do recurso ao qual os parâmetros de pesquisa se referem. Exclui campos que não são pesquisáveis. Não suportaAND
explícito (os termos são combinados implicitamente comAND
) nem parênteses. - Os parâmetros de pesquisa especiais
_query
,_filter
e_list
não são suportados. - O parâmetro
_sort
, quando usado em campos com elementos repetidos, ordena pelo primeiro elemento. Isto difere da especificação._sort
é suportado para parâmetros de pesquisa do tiponumber
,data
,string
,token
equantity
. - O modificador de pesquisa de token
:of-type
e o modificador de pesquisa de referência:identifier
não são suportados. - As pesquisas de referências canónicas não são suportadas. As referências canónicas são tratadas como referências normais.
- Quando usar o parâmetro
_type
, só pode usar os parâmetros de pesquisa comuns (a todos os recursos) e não a interseção dos tipos de recursos especificados. É suportado o seguinte subconjunto de parâmetros de pesquisa compostos:
DocumentReference-relationship
Observation-code-value-concept
Observation-code-value-date
Observation-code-value-quantity
Observation-code-value-string
Observation-combo-code-value-concept
Observation-combo-code-value-quantity
Observation-component-code-value-concept
Observation-component-code-value-quantity
Os restantes parâmetros de pesquisa compostos não são suportados.
A pesquisa através do método
POST
não aceita parâmetrosapplication/x-www-form-urlencoded
no corpo do pedido.O caráter universal (
*
) é suportado para_include
, mas não é suportado para_revinclude
.
- Os parâmetros de pesquisa
As áreas não suportadas incluem:
- A maioria das operações alargadas não está implementada.
- O tipo de conteúdo XML não é suportado.
- A operação de aplicação de patch não suporta o patch XML nem o patch
FHIRPath
. - Os pedidos HTTP HEAD não são suportados.
Áreas em que a API se desvia da especificação FHIR para permitir a retrocompatibilidade:
null
é aceite para campos obrigatórios- É aceite um código vazio para campos obrigatórios
- As referências
urn:uuid
são permitidas em pacotes de lotes quando a integridade referencial está desativada.
STU3
A declaração de capacidade do servidor indica as partes da especificação que são suportadas.
- O armazenamento e a obtenção de todos os recursos STU3 são suportados, incluindo suporte para elementos de extensão. A API aceita, armazena e devolve extensões em qualquer elemento de dados.
Todos os métodos na API RESTful que usam o tipo de conteúdo JSON são suportados, exceto:
- As interações de histórico ao nível do tipo e do sistema que obtêm o histórico em vários recursos não são suportadas. Só é possível obter o histórico de recursos de um recurso de cada vez.
- A interação batch/transaction não suporta operações de pesquisa no pacote.
A validação e a aplicação do perfil são suportadas.
Os parâmetros de pesquisa definidos pelo utilizador, incluindo pesquisas em elementos de extensão, são suportados na API v1beta1.
Toda a funcionalidade de pesquisa é suportada, exceto:
- Os parâmetros de pesquisa
Group-characteristic-value
,Sequence-coordinate
,Location-near
,Location-near-distance
,Bundle-composition
eBundle-message
não são suportados. - Os parâmetros de pesquisa que fazem correspondência fonética não são suportados.
- Os parâmetros de resultados da pesquisa
_contained
,_containedType
,_summary=count
e_summary=true
não são suportados. - O parâmetro de pesquisa especial
_content
pesquisa todos os campos do recurso referidos pelos parâmetros de pesquisa. Exclui campos que não são pesquisáveis. Não suportaAND
explícitos (os termos são combinados implicitamente com AND) nem parênteses. - Os parâmetros de pesquisa especiais
_query
,_filter
e_list
não são suportados. - O parâmetro
_sort
, quando usado em campos com elementos repetidos, ordena pelo primeiro elemento. Isto difere da especificação._sort
é suportado para parâmetros de pesquisa do tiponumber
,data
,string
,token
equantity
. - A pesquisa através do método
POST
não aceita parâmetrosapplication/x-www-form-urlencoded
no corpo do pedido. - O caráter universal (
*
) é suportado para_include
, mas não é suportado para_revinclude
.
- Os parâmetros de pesquisa
As áreas não suportadas incluem:
- A maioria das operações alargadas não está implementada.
- O tipo de conteúdo XML não é suportado.
- A operação de aplicação de patch não suporta o patch XML nem o patch FHIRPath.
Áreas em que a API se desvia da especificação FHIR para permitir a retrocompatibilidade:
null
é aceite para campos obrigatórios- É aceite um código vazio para campos obrigatórios
- As referências
urn:uuid
são permitidas em pacotes de lotes quando a integridade referencial está desativada.
DSTU2
A declaração de conformidade do servidor indica as partes da especificação que são suportadas.
- O armazenamento e a obtenção de todos os recursos DSTU2 são suportados, incluindo suporte para elementos de extensão. A API aceita, armazena e devolve extensões em qualquer elemento de dados.
- Todos os métodos na
API RESTful
que usam o tipo de conteúdo JSON são suportados, exceto:
- As interações de histórico ao nível do tipo e do sistema que obtêm o histórico em vários recursos não são suportadas. Só é possível obter o histórico de recursos de um recurso de cada vez.
- A interação batch/transaction não suporta operações de pesquisa no pacote.
- A validação e a aplicação do perfil são suportadas.
- Toda a funcionalidade de
pesquisa
é suportada, exceto:
- Os parâmetros de pesquisa
Group-characteristic-value
,Location-near
,Location-near-distance
,Bundle-composition
,Bundle-message
,Coverage-dependent
eCoverage-sequence
não são suportados. - Os parâmetros de pesquisa definidos em elementos de extensão não são suportados.
- Os parâmetros de pesquisa que fazem correspondência fonética não são suportados.
- Os parâmetros de resultados da pesquisa
_contained
,_containedType
,_summary=count
e_summary=true
não são suportados. - O parâmetro de pesquisa especial
_content
pesquisa todos os campos do recurso referidos pelos parâmetros de pesquisa. Exclui campos que não são pesquisáveis. Não suportaAND
explícitos (os termos são combinados implicitamente com AND) nem parênteses. - Os parâmetros de pesquisa especiais
_query
,_filter
e_list
não são suportados. - O parâmetro
_sort
, quando usado em campos com elementos repetidos, ordena pelo primeiro elemento. Isto difere da especificação._sort
é suportado para parâmetros de pesquisa do tiponumber
,data
,string
,token
equantity
. - A pesquisa através do método
POST
não aceita parâmetrosapplication/x-www-form-urlencoded
no corpo do pedido. - O caráter universal (
*
) é suportado para_include
, mas não é suportado para_revinclude
.
- Os parâmetros de pesquisa
As áreas não suportadas incluem:
- A maioria das operações alargadas não está implementada.
- Os parâmetros de pesquisa definidos pelo utilizador não são suportados para DSTU2.
- O tipo de conteúdo XML não é suportado.
Áreas em que a API se desvia da especificação FHIR para permitir a retrocompatibilidade:
null
é aceite para campos obrigatórios- É aceite um código vazio para campos obrigatórios
- As referências
urn:uuid
são permitidas em pacotes de lotes quando a integridade referencial está desativada.
Detalhes das operações fora da especificação publicada
- A configuração da loja FHIR inclui uma opção para notificar um tópico do Pub/Sub especificado pelo utilizador para todas as alterações aos recursos na loja. Este mecanismo de notificação é comum a todas as lojas da Cloud Healthcare API e não se destina a substituir a funcionalidade de subscrição FHIR (DSTU2, STU3, R4 e R5).
- A operação de exportação da loja FHIR para destinos do Cloud Storage oferece apenas uma exportação em massa de toda a loja. Não é uma implementação da especificação de rascunho de dados em massa da FHIR.
- A operação de importação da loja FHIR não está definida na especificação.
- A operação
Resource-purge
que remove versões do histórico de recursos não está definida na especificação. Esta API pode mudar no futuro se o processo de normas ou outras implementações da FHIR convergirem num método de API diferente para este exemplo de utilização. - O ponto final
ExecuteBundle
aceita pacoteshistory
na v1beta1 para criar versões do histórico de recursos.