Cette page a été traduite par l'API Cloud Translation.
Switch to English

Structure d'API

Cette page décrit la structure des opérations et des chemins d'accès de l'API Cloud Healthcare, ainsi que leur utilisation pour accéder aux données et les gérer.

Aperçu

Les données Healthcare des ensembles de données et des magasins de données peuvent être consultées et gérées à l'aide d'une API REST qui identifie chaque magasin de données à l'aide des éléments suivants:

  • Un projet Google Cloud
  • Un emplacement Google Cloud
  •  L'ID de l'ensemble de données
  • Le type de magasin de données
  • L'ID du magasin de données

L'API met également en œuvre des normes d'accès spécifiques à une modalité, conformes aux standards dans l'industrie pour cette modalité.

Opérations administratives

Vous pouvez effectuer des opérations administratives sur les ensembles de données et sur tous les datastores. Ils consistent principalement à créer, lire, mettre à jour et supprimer (CRUD) des ensembles de données et des magasins de données. Les opérations administratives sont cohérentes avec la plupart des API Google Cloud (Google Cloud) et ne nécessitent aucune conformité avec des normes de modalité spécifiques.

Voici quelques exemples d'opérations administratives :

  • Créer, supprimer, obtenir, répertorier et corriger des ensembles de données et des datastores
  • Paramétrer, obtenir et tester des autorisations IAM

Noms de ressources

Un nom de ressource comprend au minimum un ID de projet et un emplacement. Il peut également inclure un ensemble de données, un datastore et une des ressources enfants du datastore.

Le nom de ressource d'un datastore qui réside dans un ensemble de données de l'API Cloud Healthcare se présente comme suit :

/projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/DATA_STORE_TYPE/DATA_STORE_ID

Par exemple, le nom de ressource d'un magasin HL7v2 nommé clinical-store1 se présente comme suit:

/projects/my-project/locations/us-central1/datasets/my-dataset/hl7V2Stores/clinical-store1

Ce nom de ressource désigne un projet appelé my-project dans la région us-central1. Le projet contient un ensemble de données appelé my-dataset et celui-ci contient un magasin HL7v2 appelé clinical-store1.

Les opérations sur un emplacement, un ensemble de données, un magasin de données ou toute ressource enfant d'un magasin de données nécessitent toutes de spécifier un nom de ressource soit dans le chemin REST, soit dans la requête gRPC.

Chemins de modalité pour des opérations spécifiques à une modalité

Les opérations qui accèdent aux données dans un magasin de données spécifique à une modalité utilisent un chemin de requête composé de deux éléments: le nom de la ressource (pour identifier le magasin de données auquel accéder) et un chemin de modalité (pour identifier les données réelles).

Chemins de modalité pour les ressources FHIR

Par exemple, le chemin de requête complet pour la lecture d'une ressource patient FHIR spécifique utilisant l'ID du patient pourrait se présenter comme suit :

RESOURCE_NAME/resources/Patient/PATIENT_ID

avec /Patient/PATIENT_ID comme chemin de modalité (structuré conformément à la norme FHIR) pour la ressource Patient dont l'identifiant est spécifié par PATIENT_ID.

Chemins de modalité DICOMweb

Les requêtes DICOMweb permettant de récupérer l'intégralité des études concernant un patient donné devraient se présenter comme suit :

RESOURCE_NAME/dicomWeb/studies?PatientName=PATIENT_NAME

Autre exemple, une requête permettant de récupérer toutes les instances d'une étude et d'une série données devrait se présenter comme suit :

RESOURCE_NAME/dicomWeb/studies/STUDY_UID/series/SERIES_UID/instances

Une requête de récupération d'instance ressemblerait à ceci:

RESOURCE_NAME/dicomWeb/studies/STUDY_UID/series/SERIES_UID/instances/INSTANCE_UID

Dans tous ces exemples, la spécification du chemin de modalité est conforme à la structure de chemin standard de DICOMweb.