Declaração de conformidade FHIR

Os armazenamentos FHIR na API Cloud Healthcare são compatíveis com várias versões da especificação rápida de recursos de interoperabilidade (FHIR) publicada pela Health nível 7 internacional (HL7).

A API v1 é compatível com as seguintes versões:

Ao criar um armazenamento FHIR, você especifica a versão FHIR como um parâmetro para o método fhirStores.create. Não é possível alterar a versão FHIR após a criação do armazenamento.

A interface da API de cada armazenamento está em conformidade com a versão FHIR dessa loja. Por exemplo, a interação conformance do DSTU2 é diferente da interação capabilities do STU3, mas ambas compartilham o caminho REST /fhir/metadata. Portanto, esse caminho retorna respostas diferentes com base na versão FHIR do armazenamento.

A funcionalidade adicionada em versões posteriores do FHIR estará disponível em armazenamentos que usam versões anteriores do FHIR se não criar incompatibilidade. Por exemplo, a interação patch está disponível em um armazenamento DSTU2, mesmo que essa interação seja definida apenas a partir do STU3.

Detalhes da funcionalidade compatível na versão v1 da API FHIR

R4

A instrução de capacidade do servidor indica as partes da especificação compatíveis.

  • Armazenamento e recuperação de todos os recursos R4, incluindo suporte para elementos de extensão. A API aceita, armazena e retorna extensões em qualquer elemento de dados.
  • Todos os métodos na API RESTful que usam o tipo de conteúdo JSON são compatíveis, exceto:
    • Os níveis do tipo e do sistema história interações que recuperam o histórico de vários recursos não são suporte. O histórico de recursos só pode ser recuperado para um recurso por vez.
    • A interação em lote/transação não é compatível com operações de pesquisa dentro do pacote.
  • Perfil validação e aplicação.
  • A API v1beta1 dá suporte aos parâmetros de pesquisa definidos pelo usuário, incluindo pesquisas em elementos de extensão.

  • Toda a funcionalidade de pesquisa é compatível, exceto:

    • Os parâmetros de pesquisa Group-characteristic-value, Location-near, Bundle-composition e Bundle-message não são compatíveis.
    • Os parâmetros de pesquisa que executam a correspondência telefônica não são compatíveis.
    • Os parâmetros de resultado da pesquisa _contained, _containedType, _summary=count e _summary=true não são compatíveis.
    • O parâmetro de pesquisa especial _content pesquisa todos os campos do recurso aos quais os parâmetros de pesquisa se referem. Ele exclui campos que não são pesquisáveis. Ele não é compatível com AND explícito (os termos são combinados implicitamente com AND) ou com colchetes.
    • Não há suporte aos parâmetros de pesquisa especiais _query, _filter e _list.
    • O parâmetro _sort, quando usado em campos com elementos repetidos, classifica pelo primeiro elemento; isso é diferente da especificação. Todos os parâmetros de pesquisa compatíveis estão qualificados para _sort, exceto o parâmetro de pesquisa especial _content.
    • Não há suporte ao modificador de pesquisa de token :of-type e o modificador de pesquisa de referência :identifier.
    • As pesquisas de referência canônica não são suportadas. As referências canônicas são tratadas como referências normais.
    • Ao usar o parâmetro _type, apenas os parâmetros de pesquisa comuns (para todos os recursos) podem ser usados, e não a interseção dos tipos de recursos especificados.

    • Os seguintes subconjuntos de parâmetros de pesquisa compostos são compatíveis:

      • 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 parâmetros de pesquisa compostos restantes não são compatíveis.

    • A pesquisa que usa o método POST não aceita parâmetros application/x-www-form-urlencoded no corpo da solicitação.

    • O caractere curinga (*) é aceito para _include, mas não para _revinclude.

As áreas que não são compatíveis incluem:

  • A maioria das operações estendidas não é implementada.
  • O tipo de conteúdo XML não é suportado.
  • A operação de patch não é compatível com o patch XML ou com o patch FHIRPath.
  • As solicitações HTTP HEAD não são compatíveis.

Áreas em que a API se desvia da especificação FHIR para permitir a compatibilidade com versões anteriores:

  • null é aceito para campos obrigatórios
  • Um código em branco é aceito nos campos obrigatórios
  • urn:uuid referências são permitidas em pacotes de lote

STU3

A instrução de capacidade do servidor indica as partes da especificação compatíveis.

  • Armazenamento e recuperação de todos os Recursos do STU3 é suportado, incluindo suporte para elementos de extensão. A API aceita, armazena e retorna extensões em qualquer elemento de dados.

  • Todos os métodos na API RESTful que usam o tipo de conteúdo JSON são aceitos, exceto para:

    • As interações de histórico no nível do tipo e do sistema que recuperam o histórico em vários recursos não são compatíveis. O histórico de recursos só pode ser recuperado para um recurso por vez.
    • A interação em lote/transação não é compatível com operações de pesquisa dentro do pacote.

  • Perfil validação e aplicação.

  • A API v1beta1 dá suporte aos parâmetros de pesquisa definidos pelo usuário, incluindo pesquisas em elementos de extensão.

  • Toda a pesquisa há suporte para a funcionalidade, com exceção de:

    • Os parâmetros de pesquisa Group-characteristic-value, Sequence-coordinate, Location-near, Location-near-distance, Bundle-composition e Bundle-message não são compatíveis.
    • Os parâmetros de pesquisa que executam a correspondência telefônica não são compatíveis.
    • Os parâmetros de resultado da pesquisa _contained, _containedType, _summary=count e _summary=true não são compatíveis.
    • O parâmetro de pesquisa especial _content pesquisa todos os campos do recurso que são referenciados pelos parâmetros de pesquisa. Ele exclui campos que não são pesquisáveis. Ele não suporta AND explícito (os termos são combinados implicitamente com AND) ou colchetes.
    • Não há suporte aos parâmetros de pesquisa especiais _query, _filter e _list.
    • O parâmetro _sort, quando usado em campos com elementos repetidos, classifica pelo primeiro elemento; isso é diferente da especificação. Todos os parâmetros de pesquisa compatíveis estão qualificados para _sort, exceto o parâmetro de pesquisa especial _content.
    • A pesquisa que usa o método POST não aceita parâmetros application/x-www-form-urlencoded no corpo da solicitação.
    • O caractere curinga (*) é compatível com _include, mas não com _revinclude

As áreas que não são compatíveis incluem:

  • A maioria das operações estendidas não é implementada.
  • O tipo de conteúdo XML não é suportado.
  • A operação patch não é compatível com o patch XML ou FHIRPath.

Áreas em que a API se desvia da especificação FHIR para permitir a compatibilidade com versões anteriores:

  • null é aceito para campos obrigatórios
  • Um código em branco é aceito nos campos obrigatórios
  • urn:uuid referências são permitidas em pacotes de lote

DSTU2

A declaração de conformidade do servidor indica as partes da especificação que são compatíveis.

  • O armazenamento e a recuperação de todos os recursos DSTU2 são compatíveis, incluindo suporte para elementos de extensão. A API aceita, armazena e retorna extensões em qualquer elemento de dados.
  • Todos os métodos na API RESTful que usam o tipo de conteúdo JSON são compatíveis, exceto:
    • As interações de histórico no nível do tipo e do sistema que recuperam o histórico em vários recursos não são compatíveis. O histórico de recursos só pode ser recuperado para um recurso por vez.
    • O lote/transação interação não oferece suporte para operações de pesquisa dentro do pacote.
  • Perfil validação e aplicação.
  • Todos os pesquisar há suporte para a funcionalidade, com exceção de:
    • Os parâmetros de pesquisa Group-characteristic-value, Location-near, Location-near-distance, Bundle-composition, Bundle-message, Coverage-dependent e Coverage-sequence não são compatíveis.
    • Os parâmetros de pesquisa definidos nos elementos da extensão não são compatíveis.
    • Os parâmetros de pesquisa que executam a correspondência telefônica não são compatíveis.
    • Os parâmetros de resultado da pesquisa _contained, _containedType, _summary=count e _summary=true não são compatíveis.
    • O parâmetro de pesquisa especial _content pesquisa todos os campos do recurso que são referenciados pelos parâmetros de pesquisa. Ele exclui campos que não são pesquisáveis. Ele não suporta AND explícito (os termos são combinados implicitamente com AND) ou colchetes.
    • Não há suporte aos parâmetros de pesquisa especiais _query, _filter e _list.
    • O parâmetro _sort, quando usado em campos com elementos repetidos, classifica pelo primeiro elemento; isso é diferente da especificação. Todos os parâmetros de pesquisa compatíveis estão qualificados para _sort, exceto o parâmetro de pesquisa especial _content.
    • A pesquisa que usa o método POST não aceita parâmetros application/x-www-form-urlencoded no corpo da solicitação.
    • O caractere curinga (*) é aceito para _include, mas não para _revinclude.

As áreas que não são compatíveis incluem:

  • Mais frequentes operações estendidas não sejam implementadas.
  • Não há suporte aos parâmetros de pesquisa definidos pelo usuário 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 compatibilidade com versões anteriores:

  • null é aceito para campos obrigatórios
  • Um código em branco é aceito nos campos obrigatórios
  • urn:uuid referências são permitidas em pacotes de lote

Detalhes das operações fora da especificação publicada

  • A configuração do armazenamento FHIR inclui uma opção para notificar um tópico do Pub/Sub especificado pelo usuário para todas as alterações nos recursos do armazenamento. Esse mecanismo de notificação é comum em todos os armazenamentos da API Cloud Healthcare e não se destina a substituir a funcionalidade FHIR Subscription (DSTU2, STU3 e R4). .
  • 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 FHIR.
  • A operação de importação de armazenamento FHIR não está definida na especificação.
  • A operação Resource-purge que remove versões históricas de recursos não é definida na especificação. Essa API poderá mudar no futuro se o processo de padrões ou outras implementações de FHIR forem convertidas em um método de API diferente para esse caso de uso.
  • O endpoint ExecuteBundle aceita pacotes history na v1beta1 para criar versões históricas de recursos.