Mettre à jour une ressource FHIR - AWS HealthLake

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Mettre à jour une ressource FHIR

L'updateinteraction FHIR crée une nouvelle version actuelle pour une ressource existante ou crée une version initiale si aucune ressource n'existe déjà pour la ressource donnéeid. Pour plus d'informations, consultez la updatedocumentation de l' RESTful API FHIR R4.

Pour mettre à jour une ressource FHIR

  1. Collectez HealthLake region et datastoreId valorisez. Pour de plus amples informations, veuillez consulter Obtenir les propriétés du magasin de données.

  2. Déterminez le type de FHIR Resource à mettre à jour et collectez la id valeur associée. Pour de plus amples informations, veuillez consulter Types de ressource.

  3. Construisez une URL pour la demande en utilisant les valeurs collectées pour HealthLake region etdatastoreId. Incluez également le Resource type FHIR et son associéid. Pour afficher le chemin complet de l'URL dans l'exemple suivant, faites défiler le curseur sur le bouton Copier.

    PUT https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
  4. Construisez un JSON corps pour la demande, en spécifiant les mises à jour des données FHIR à effectuer. Dans le cadre de cette procédure, enregistrez le fichier sousupdate-patient.json.

    { "id": "2de04858-ba65-44c1-8af1-f2fe69a977d9", "resourceType": "Patient", "active": true, "name": [ { "use": "official", "family": "Doe", "given": [ "Jane" ] }, { "use": "usual", "given": [ "Jane" ] } ], "gender": "female", "birthDate": "1985-12-31" }
  5. Envoyez la demande . L'updateinteraction FHIR utilise une PUT demande avec AWS signature version 4 ou SMART sur autorisation FHIR. L'curlexemple suivant met à jour une Patient ressource dans HealthLake. Pour afficher l'exemple dans son intégralité, faites défiler la souris sur le bouton Copier.

    SigV4

    Autorisation SigV4

    curl --request PUT \ 'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id' \ --aws-sigv4 'aws:amz:region:healthlake' \ --user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \ --header "x-amz-security-token:$AWS_SESSION_TOKEN" \ --header 'Accept: application/json' \ --data @update-patient.json

    Votre demande renverra un code d'état 200 HTTP si une ressource existante est mise à jour ou un code d'état 201 HTTP si une nouvelle ressource est créée.

    SMART on FHIR

    Exemple d'autorisation SMART sur FHIR pour le type de IdentityProviderConfigurationdonnées.

    { "AuthorizationStrategy": "SMART_ON_FHIR", "FineGrainedAuthorizationEnabled": true, "IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name", "Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}" }

    L'appelant peut attribuer des autorisations dans le lambda d'autorisation. Pour de plus amples informations, veuillez consulter OAuth Éscopes 2.0.

    AWS Console

    1. Connectez-vous à la page Exécuter une requête sur la HealthLake console.

    2. Dans la section Paramètres de requête, effectuez les sélections suivantes.

    • ID du magasin de données : choisissez un identifiant de magasin de données pour générer une chaîne de requête.

    • Type de requête : choisissezUpdate (PUT).

    • Type de ressource : choisissez le type de ressource FHIR à mettre à jour ou à créer.

    • Corps de la demande : créez un corps JSON pour la demande, en spécifiant les données FHIR avec lesquelles mettre à jour la ressource.

    3. Choisissez Exécuter la requête.

Mise à jour des ressources du FHIR en fonction des conditions

La mise à jour conditionnelle vous permet de mettre à jour une ressource existante en fonction de certains critères de recherche d'identification, plutôt que selon un FHIR id logique. Lorsque le serveur traite la mise à jour, il effectue une recherche à l'aide de ses fonctionnalités de recherche standard pour le type de ressource, dans le but de résoudre une seule logique id pour la demande.

L'action entreprise par le serveur dépend du nombre de correspondances qu'il trouve :

  • Aucune correspondance, aucune information id fournie dans le corps de la requête : le serveur crée la ressource FHIR.

  • Aucune correspondance, id fournie et la ressource n'existe pas déjà avec le id : Le serveur traite l'interaction comme une interaction Mettre à jour en tant qu'interaction Créer.

  • Aucune correspondance, id fournie et existante : le serveur rejette la mise à jour avec une 409 Conflict erreur.

  • Une correspondance, aucune ressource id fournie OU (ressource id fournie et elle correspond à la ressource trouvée) : Le serveur effectue la mise à jour par rapport à la ressource correspondante comme ci-dessus où, si la ressource a été mise à jour, le serveur DOIT renvoyer un200 OK.

  • Une correspondance, ressource id fournie mais ne correspondant pas à la ressource trouvée : le serveur renvoie une 409 Conflict erreur indiquant que la spécification de l'identifiant du client posait problème, de préférence avec un OperationOutcome

  • Correspondances multiples : le serveur renvoie une 412 Precondition Failed erreur indiquant que les critères du client n'étaient pas suffisamment sélectifs, de préférence avec un OperationOutcome

L'exemple suivant met à jour une Patient ressource dont le nom est Peter, la date de naissance est le 1er janvier 2000 et le numéro de téléphone est 1234567890.

PUT https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?name=peter&birthdate=2000-01-01&phone=1234567890

Configuration du niveau de validation pour les mises à jour des ressources

Lors de la mise à jour d'une ressource FHIR, vous pouvez éventuellement spécifier un en-tête x-amzn-healthlake-fhir-validation-level HTTP pour configurer un niveau de validation pour la ressource. AWS HealthLake prend actuellement en charge les niveaux de validation suivants :

  • strict: Les ressources sont validées en fonction de l'élément de profil de la ressource ou de la spécification R4 si aucun profil n'est présent. Il s'agit du niveau de validation par défaut pour AWS HealthLake.

  • structure-only: Les ressources sont validées par rapport à R4, en ignorant les profils référencés.

  • minimal: Les ressources sont validées de manière minimale, sans tenir compte de certaines règles R4. Les ressources qui échouent aux vérifications de structure requises search/analytics seront mises à jour pour inclure un avertissement d'audit.

Les ressources mises à jour avec le niveau de validation minimal peuvent être ingérées dans une banque de données malgré l'échec de la validation requise pour l'indexation des recherches. Dans ce cas, les ressources seront mises à jour pour inclure une extension spécifique à Healthlake afin de documenter ces échecs :

{ "url": "http://healthlake.amazonaws.com/fhir/StructureDefinition/validation-issue", "valueString": "{\"resourceType\":\"OperationOutcome\",\"issue\":[{\"severity\":\"error\",\"code\":\"processing\",\"details\":{\"text\":\"FHIR resource in payload failed FHIR validation rules.\"},\"diagnostics\":\"FHIR resource in payload failed FHIR validation rules.\"}]}" }

En outre, l'en-tête de réponse HTTP suivant sera inclus avec la valeur « true » :

x-amzn-healthlake-validation-issues : true
Note

Notez que les données ingérées qui sont mal formées conformément à la spécification R4 peuvent ne pas être consultables comme prévu si ces erreurs sont présentes.