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 :
- R4 version 4.0.1 (version 4)
- STU3 version 3.0.1 (version 3 – Standard pour la version d'essai)
- DSTU2 version 1.0.2 (version préliminaire pour la version d'essai)
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 interactions d'historique au niveau du type et du système qui récupèrent l'historique de plusieurs ressources ne sont pas acceptées. L'historique des ressources ne peut être récupéré que pour une ressource à la fois.
- L'interaction lot/transaction ne prend pas en charge les opérations de recherche au sein du groupe.
- La validation et l'application du profil sont acceptées.
- 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
etBundle-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 jointuresAND
explicites (les termes sont implicitement combinés avecAND
) 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ètresapplication/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 paramètres de recherche
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 bundles par lot.
STU3
La déclaration de capacités du serveur indique les parties de la spécification qui sont compatibles.
- 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 interactions d'historique au niveau du type et du système qui récupèrent l'historique de plusieurs ressources ne sont pas acceptées. L'historique des ressources ne peut être récupéré que pour une ressource à la fois.
- La batch/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
etBundle-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 jointuresAND
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ètresapplication/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 paramètres de recherche
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 de toutes les ressources DSTU2 sont acceptés, 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 acceptées, à 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 acceptées. L'historique des ressources ne peut être récupéré que pour une ressource à la fois.
- L'interaction lot/transaction ne prend pas en charge les opérations de recherche au sein du groupe.
- Profil la validation et l'application sont possibles.
- Toutes les fonctionnalités de recherche sont acceptées, à l'exception des suivantes :
- Les paramètres de recherche
Group-characteristic-value
,Location-near
,Location-near-distance
,Bundle-composition
,Bundle-message
,Coverage-dependent
etCoverage-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 jointuresAND
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ètresapplication/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 paramètres de recherche
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 bundles 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 groupeshistory
dans la version v1beta1 pour créer des versions historiques des ressources.