Déclaration de conformité FHIR

Les magasins FHIR dans l'API Cloud Healthcare sont compatibles avec plusieurs versions de la spécification FHIR (Fast Healthcare Interoperability Resources) publiée par HL7 (Health Level 7 International).

L'API v1 est compatible avec les versions suivantes :

Lorsque vous créez un magasin FHIR, vous spécifiez la version FHIR en tant que paramètre dans la méthode fhirStores.create. Vous ne pouvez pas modifier la version FHIR une fois le magasin créé.

L'interface API de chaque magasin est conforme à la version FHIR de celui-ci. Par exemple, l'interaction conformance DSTU2 est différente de l'interaction capabilities STU3, mais les deux partagent le chemin REST /fhir/metadata. Ce chemin renvoie donc des réponses différentes en fonction de la version FHIR du magasin.

Les fonctionnalités ajoutées dans les versions FHIR ultérieures sont disponibles dans les magasins utilisant des versions FHIR antérieures si elles ne créent pas d'incompatibilité. Par exemple, l'interaction patch est disponible dans un magasin DSTU2, même si cette interaction est uniquement définie à partir de STU3.

Détails sur les fonctionnalités compatibles dans l'API v1 par version FHIR

R4

Le serveur instruction de capacité indique les parties de la spécification qui sont prises en charge.

  • Le stockage et la récupération de toutes les ressources R4, y compris la compatibilité avec les éléments d'extension. L'API accepte, stocke et renvoie les extensions sur tout élément de données.
  • Toutes les méthodes API RESTful qui utilisent le type de contenu JSON sont acceptés, sauf pour:
    • Les niveaux type et système historique qui récupèrent l'historique sur plusieurs ressources ne sont pas compatibles. L'historique des ressources ne peut être récupéré que pour une ressource à la fois.
    • La batch/transaction (lot/transaction) l'interaction ne prend pas en charge les opérations de recherche dans le bundle.
  • Profil la validation et l'application sont possibles.
  • Les paramètres de recherche définis par l'utilisateur, y compris les recherches sur les éléments d'extension, sont compatibles avec l'API v1beta1.

  • Toutes les recherches sont prises en charge, à l'exception des cas suivants:

    • Les paramètres de recherche Group-characteristic-value, Location-near, Bundle-composition et Bundle-message ne sont pas acceptés.
    • Les paramètres de recherche qui effectuent une correspondance phonétique ne sont pas acceptés.
    • Les paramètres de résultat de recherche _contained, _containedType, _summary=count et _summary=true ne sont pas acceptés.
    • Le paramètre de recherche spécial _content recherche tous les champs de la ressource auxquels les paramètres de recherche font référence. Il exclut les champs qui ne sont pas inclus dans l'index de recherche. Il n'est pas compatible avec les jointures AND explicites (les termes sont implicitement combinés avec AND) ou les crochets.
    • Les paramètres de recherche spéciaux _query, _filter et _list ne sont pas acceptés.
    • Le paramètre _sort, lorsqu'il est utilisé sur des champs comportant des éléments répétés, effectue le tri en fonction du premier élément. Cela diffère de la spécification. Tous les paramètres de recherche acceptés sont éligibles pour _sort, à l'exception du paramètre de recherche spécial _content.
    • Le modificateur de recherche de jetons :of-type et le modificateur de recherche de référence :identifier ne sont pas acceptés.
    • Les recherches de références canoniques ne sont pas acceptées. Les références canoniques sont traitées comme des références normales.
    • Lorsque vous utilisez le paramètre _type, seuls les paramètres de recherche communs (à toutes les ressources) peuvent être utilisés, et non l'intersection des types de ressources spécifiés.

    • Les sous-ensembles de paramètres de recherche composites suivants sont acceptés :

      • 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

      Les autres paramètres de recherche composites ne sont pas acceptés.

    • La recherche à l'aide de la méthode POST n'accepte pas les paramètres application/x-www-form-urlencoded dans le corps de la requête.

    • Le caractère générique (*) est accepté dans _include, mais pas dans _revinclude.

Les zones non acceptées sont les suivantes :

  • La plupart des opérations étendues ne sont pas implémentées.
  • Le type de contenu XML n'est pas accepté.
  • L'opération de correctif n'est pas compatible avec les correctifs XML ou FHIRPath.
  • Les requêtes HTTP HEAD ne sont pas acceptées.

Domaines dans lesquels l'API s'écarte de la spécification FHIR pour permettre la rétrocompatibilité:

  • null est accepté pour les champs obligatoires
  • Un code vide est accepté pour les champs obligatoires
  • Les références urn:uuid sont autorisées dans les groupes par lot

STU3

Le serveur instruction de capacité indique les parties de la spécification qui sont prises en charge.

  • le stockage et la récupération Ressources STU3 est pris en charge, y compris pour éléments d'extension. L'API accepte, stocke et renvoie les extensions sur tout élément de données.

  • Toutes les méthodes API RESTful qui utilisent le type de contenu JSON sont acceptés, sauf pour:

    • Les niveaux type et système historique qui récupèrent l'historique sur plusieurs ressources ne sont pas compatibles. L'historique des ressources ne peut être récupéré que pour une ressource à la fois.
    • La batch/transaction (lot/transaction) l'interaction ne prend pas en charge les opérations de recherche dans le bundle.

  • Profil la validation et l'application sont possibles.

  • Les paramètres de recherche définis par l'utilisateur, y compris les recherches sur les éléments d'extension, sont compatibles avec l'API v1beta1.

  • Toutes les recherches sont prises en charge, à l'exception des cas suivants:

    • Les paramètres de recherche Group-characteristic-value, Sequence-coordinate, Location-near, Location-near-distance, Bundle-composition et Bundle-message ne sont pas acceptés.
    • Les paramètres de recherche qui effectuent une correspondance phonétique ne sont pas acceptés.
    • Les paramètres de résultat de recherche _contained, _containedType, _summary=count et _summary=true ne sont pas acceptés.
    • Le paramètre de recherche spécial _content recherche tous les champs de la ressource référencés par les paramètres de recherche. Il exclut les champs qui ne sont pas inclus dans l'index de recherche. Il n'est pas compatible avec les jointures AND explicites (les termes sont implicitement combinés avec AND) ou les crochets.
    • Les paramètres de recherche spéciaux _query, _filter et _list ne sont pas acceptés.
    • Le paramètre _sort, lorsqu'il est utilisé sur des champs comportant des éléments répétés, effectue le tri en fonction du premier élément. Cela diffère de la spécification. Tous les paramètres de recherche acceptés sont éligibles pour _sort, à l'exception du paramètre de recherche spécial _content.
    • La recherche à l'aide de la méthode POST n'accepte pas les paramètres application/x-www-form-urlencoded dans le corps de la requête.
    • Le caractère générique (*) est accepté dans _include, mais pas dans _revinclude.

Les zones non acceptées sont les suivantes :

  • La plupart des opérations étendues ne sont pas implémentées.
  • Le type de contenu XML n'est pas accepté.
  • L'opération de correctif n'est pas compatible avec le correctif XML ni le correctif FHIRPath.

Domaines dans lesquels l'API s'écarte de la spécification FHIR pour permettre la rétrocompatibilité:

  • null est accepté pour les champs obligatoires
  • Un code vide est accepté pour les champs obligatoires
  • Les références urn:uuid sont autorisées dans les groupes par lot

DSTU2

Le serveur déclaration de conformité indique les parties de la spécification qui sont prises en charge.

  • le stockage et la récupération Ressources DSTU2 est pris en charge, y compris pour éléments d'extension. L'API accepte, stocke et renvoie les extensions sur tout élément de données.
  • Toutes les méthodes API RESTful qui utilisent le type de contenu JSON sont acceptés, sauf pour:
    • Les niveaux type et système historique qui récupèrent l'historique sur plusieurs ressources ne sont pas compatibles. L'historique des ressources ne peut être récupéré que pour une ressource à la fois.
    • La batch/transaction (lot/transaction) l'interaction ne prend pas en charge les opérations de recherche dans le bundle.
  • Profil la validation et l'application sont possibles.
  • Toutes les recherche sont prises en charge, à l'exception des cas suivants:
    • Les paramètres de recherche Group-characteristic-value, Location-near, Location-near-distance, Bundle-composition, Bundle-message, Coverage-dependent et Coverage-sequence ne sont pas acceptés.
    • Les paramètres de recherche définis sur des éléments d'extension ne sont pas acceptés.
    • Les paramètres de recherche qui effectuent une correspondance phonétique ne sont pas acceptés.
    • Les paramètres de résultat de recherche _contained, _containedType, _summary=count et _summary=true ne sont pas acceptés.
    • Le paramètre de recherche spécial _content recherche tous les champs de la ressource référencés par les paramètres de recherche. Il exclut les champs qui ne sont pas inclus dans l'index de recherche. Il n'est pas compatible avec les jointures AND explicites (les termes sont implicitement combinés avec AND) ou les crochets.
    • Les paramètres de recherche spéciaux _query, _filter et _list ne sont pas acceptés.
    • Le paramètre _sort, lorsqu'il est utilisé sur des champs comportant des éléments répétés, effectue le tri en fonction du premier élément. Cela diffère de la spécification. Tous les paramètres de recherche acceptés sont éligibles pour _sort, à l'exception du paramètre de recherche spécial _content.
    • La recherche à l'aide de la méthode POST n'accepte pas les paramètres application/x-www-form-urlencoded dans le corps de la requête.
    • Le caractère générique (*) est accepté dans _include, mais pas dans _revinclude.

Les zones non acceptées sont les suivantes :

  • La plupart des opérations étendues ne sont pas implémentées.
  • Les paramètres de recherche définis par l'utilisateur ne sont pas compatibles avec DSTU2.
  • Le type de contenu XML n'est pas accepté.

Domaines dans lesquels l'API s'écarte de la spécification FHIR pour permettre la rétrocompatibilité:

  • null est accepté pour les champs obligatoires
  • Un code vide est accepté pour les champs obligatoires
  • Les références urn:uuid sont autorisées dans les groupes par lot

Détails des opérations en dehors de la spécification publiée

  • La configuration du magasin FHIR comprend une option permettant de notifier à un sujet Pub/Sub spécifié par l'utilisateur toutes les modifications apportées aux ressources du magasin. Ce mécanisme de notification est commun à tous les magasins de l'API Cloud Healthcare et ne vise pas à remplacer la fonctionnalité d'abonnement FHIR (DSTU2, STU3 et R4).
  • L'opération d'un exportation dmagasin FHIR vers des destinations Cloud Storage ne propose qu'une exportation groupée de l'ensemble du magasin. Il ne s'agit pas d'une implémentation des Données groupées FHIR à l'état de brouillon de spécification.
  • L'opération d'importation de magasin FHIR n'est pas définie dans la spécification.
  • L'opération Resource-purge, qui supprime les versions historiques des ressources, n'est pas définie dans la spécification. Cette API pourrait changer à l'avenir si le processus de normalisation ou d'autres mises en œuvre FHIR convergent vers une méthode API différente pour ce cas d'utilisation.
  • Le point de terminaison ExecuteBundle accepte les groupes history dans la version v1beta1 pour créer des versions historiques des ressources.