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

R5

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

  • Armazenamento e recuperação de todos os recursos R5, 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.
    • A interação em lote/transação não é compatível com operações de pesquisa dentro do pacote.
  • A validação e aplicação de perfil são compatíveis.
  • 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, Location-contains, DocumentReference-relationship, Bundle-composition, Bundle-message, Observation-component-value-canonical,Observation-value-canonical, QuestionnaireResponse-item-subject e Composition-section-text 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 suporta AND explícito (os termos são combinados implicitamente com AND) ou colchetes.
    • Não há suporte aos parâmetros de pesquisa especiais Resource-query, Resource-filter, Resource-language, Resource-in e Resource-list.
    • O parâmetro _sort, quando usado em campos com elementos repetidos, classifica pelo primeiro elemento; isso é diferente da especificação. _sort é compatível com parâmetros de pesquisa do tipo number, data, string, token e quantity.
    • Não há suporte ao modificador de pesquisa de token :of-type, :code-text, text-advanced, e :text e o modificador de pesquisa de referência :identifier, not-in, text-advanced, e :code-text. O modificador contains para pesquisas de URI não é compatível.
    • As pesquisas de referência canônica não são suportadas. As referências canônicas são tratadas como referências normais. Os modificadores above e below não são compatíveis.
    • 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:

      • 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 (*) é compatível com _include, mas está indisponível para _revinclude.

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

  • 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.

Alguns aspectos da API se desviaram da especificação FHIR devido à compatibilidade com versões anteriores em versões anteriores do FHIR. Esses problemas foram corrigidos na R5:

  • Quando a validação de campo obrigatório está ativada, os campos null e os campos vazios (por exemplo, {}) agora são rejeitados.
  • O UpperCamelCase não é mais compatível com campos de recursos em JSON.
  • As referências urn:uuid não são permitidas em pacotes em lote, independentemente de a integridade referencial estar desativada ou não. Os pacotes em lote nunca reescrevem referências.
  • Os pacotes de transações são mais rigorosos na reescrita de referências do que antes e erros em FullUrls inválidos em entradas, conforme definido pela especificação: https://www.hl7.org/fhir/bundle.html#references.
  • As referências que parecem referências de recursos precisam ter IDs válidos.
  • A validação de perfil base está ativada para solicitações PATCH.

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:
    • 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.
  • A validação e aplicação de perfil são compatíveis.
  • 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. _sort é compatível com parâmetros de pesquisa do tipo number, data, string, token e quantity.
    • 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 (*) é compatível com _include, mas está indisponível 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 vazio é aceito para campos obrigatórios
  • As referências urn:uuid são permitidas em pacotes em lote quando a integridade referencial está desativada.

STU3

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

  • O armazenamento e a recuperação de todos os recursos STU3 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.
    • A interação em lote/transação não é compatível com operações de pesquisa dentro do pacote.

  • A validação e aplicação de perfil são compatíveis.

  • 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, 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. _sort é compatível com parâmetros de pesquisa do tipo number, data, string, token e quantity.
    • 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 está indisponível 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 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 vazio é aceito para campos obrigatórios
  • As referências urn:uuid são permitidas em pacotes em lote quando a integridade referencial está desativada.

DSTU2

A declaração de conformidade do servidor indica as partes da especificaçã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.
    • A interação em lote/transação não é compatível com operações de pesquisa dentro do pacote.
  • A validação e aplicação de perfil são compatíveis.
  • Toda a funcionalidade de pesquisa é compatível, exceto:
    • 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. _sort é compatível com parâmetros de pesquisa do tipo number, data, string, token e quantity.
    • 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 está indisponível para _revinclude.

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

  • A maioria das operações estendidas não é implementada.
  • 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 vazio é aceito para campos obrigatórios
  • As referências urn:uuid são permitidas em pacotes em lote quando a integridade referencial está desativada.

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, R4, e R5)) funcionalidade.
  • A operação de exportação do repositório FHIR para destinos do Cloud Storage oferece apenas uma exportação em massa de todo o repositório. 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.