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

La déclaration de capacité du serveur indique les parties de la spécification qui sont compatibles.

  • 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 de l'API RESTful qui utilisent le type de contenu JSON sont compatibles, à l'exception de :
    • Les interactions d'historique au niveau du type et du système qui récupèrent l'historique de plusieurs ressources ne sont pas compatibles. L'historique des ressources ne peut être récupéré que pour une ressource à la fois.
    • L'interaction batch/transaction n'est pas compatible avec les opérations de recherche dans le bundle.
  • La validation et l'application du profil 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 fonctionnalités de recherche sont compatibles, à l'exception des suivantes:

    • 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 mises en œuvre.
  • 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.

Régions dans lesquelles l'API s'écarte de la spécification FHIR pour permettre une rétrocompatibilité:

  • null est accepté pour les champs obligatoires
  • Vous devez indiquer un code vide dans les champs obligatoires.
  • Les références urn:uuid sont autorisées dans les lots

STU3

La déclaration de capacité du serveur indique les parties de la spécification qui sont compatibles.

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

  • Toutes les méthodes de l'API RESTful qui utilisent le type de contenu JSON sont compatibles, à l'exception des méthodes suivantes:

    • Les interactions d'historique au niveau du type et du système qui récupèrent l'historique de plusieurs ressources ne sont pas compatibles. L'historique des ressources ne peut être récupéré que pour une ressource à la fois.
    • L'interaction batch/transaction n'est pas compatible avec les opérations de recherche dans le bundle.

  • La validation et l'application du profil 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 fonctionnalités de recherche sont compatibles, à l'exception des suivantes:

    • 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 mises en œuvre.
  • 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.

Régions dans lesquelles l'API s'écarte de la spécification FHIR pour permettre une rétrocompatibilité:

  • null est accepté pour les champs obligatoires
  • Vous devez indiquer un code vide dans les champs obligatoires.
  • Les références urn:uuid sont autorisées dans les lots

DSTU2

La déclaration de conformité du serveur indique les parties de la spécification qui sont compatibles.

  • Le stockage et la récupération de toutes les ressources DSTU2 sont pris en charge, y compris les éléments d'extension. L'API accepte, stocke et renvoie les extensions sur tout élément de données.
  • Toutes les méthodes de l'API RESTful qui utilisent le type de contenu JSON sont compatibles, à l'exception de :
    • Les interactions d'historique au niveau du type et du système qui récupèrent l'historique de plusieurs ressources ne sont pas compatibles. L'historique des ressources ne peut être récupéré que pour une ressource à la fois.
    • L'interaction batch/transaction n'est pas compatible avec les opérations de recherche dans le bundle.
  • La validation et l'application du profil sont possibles.
  • Toutes les fonctionnalités de recherche sont compatibles, à l'exception des suivantes :
    • 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 mises en œuvre.
  • 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é.

Régions dans lesquelles l'API s'écarte de la spécification FHIR pour permettre une rétrocompatibilité:

  • null est accepté pour les champs obligatoires
  • Vous devez indiquer un code vide dans les champs obligatoires.
  • Les références urn:uuid sont autorisées dans les lots

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 de la spécification brouillon FHIR Bulk Data.
  • 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 bundles history dans v1beta1 pour créer des versions historiques des ressources.