Fonctionnalités de conformité du CMS - AWS HealthLake
Points de terminaison d'interopérabilité CMSCloudWatch Mesures améliorées pour la conformité aux CMS

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.

Fonctionnalités de conformité du CMS

AWS HealthLake fournit des fonctionnalités pour vous aider à répondre aux exigences d'interopérabilité et de conformité des CMS (Centers for Medicare & Medicaid Services). Ces fonctionnalités vous permettent de suivre l'utilisation des API par catégorie de CMS et de signaler ensuite les mesures d'utilisation à des fins de conformité.

Points de terminaison d'interopérabilité CMS

Présentation de

HealthLake fournit quatre points de terminaison d'interopérabilité du CMS qui correspondent aux catégories d'API mandatées par le CMS. L'URL de base sous-jacente de votre HealthLake banque de données ne change pas. Ces points de terminaison fournissent simplement un moyen de classer et de suivre vos appels d'API à des fins de reporting CMS.

Objectif

L'objectif principal de ces points de terminaison d'interopérabilité est de permettre aux clients de :

  • Suivez facilement les transactions d'API par catégorie de CMS

  • Signalez automatiquement les mesures d'utilisation pour garantir la conformité au CMS

  • Maintenir les flux de travail FHIR existants avec un minimum de modifications

Tous les appels d'API fonctionnent de la même manière, que vous utilisiez le point de terminaison d'interopérabilité ou le point de terminaison FHIR standard. La seule différence réside dans la manière dont les transactions sont classées dans les métriques. CloudWatch

Points de terminaison d'interopérabilité CMS pris en charge

Catégorie CMS Endpoint d'interopérabilité Exemple d'utilisation
Accès pour les patients /patientaccess/v2/r4 baseURL/patientaccess/v2/r4/Patient/123
Accès du fournisseur /​provideraccess/v2/r4 baseURL/​provideraccess/v2/r4/Observation?patient=123
Payeur à payeur /payertopayerdx/v2/r4 baseURL/payertopayerdx/v2/r4/Practitioner/456
Service d'authentification préalable /priorauthservice/v2/r4 baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789

Comment fonctionnent les points de terminaison d'interopérabilité

Appel HealthLake d'API standard :

baseURL/resourceType/[id]
baseURL/resourceType?[parameters]

Avec CMS Interoperability Endpoint :

baseURL/interoperability-endpoint/resourceType/[id]
baseURL/interoperability-endpoint/resourceType?[parameters]

Le chemin du point de terminaison d'interopérabilité est simplement inséré entre votre URL de base et le type de ressource. Après le chemin du point de terminaison d'interopérabilité, tout reste exactement le même que celui de vos appels d'API actuels.

Exemples d’utilisation

Exemple 1 : API d'accès aux patients

Appel d'API en cours (fonctionne toujours) :

curl -X GET \
  https://healthlake.us-east-1.amazonaws.com/datastore/abc123/r4/Patient/123 \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/fhir+json"

Avec le point de terminaison d'interopérabilité Patient Access (pour le suivi du CMS) :

curl -X GET \
  https://healthlake.us-east-1.amazonaws.com/datastore/abc123/patientaccess/v2/r4/Patient/123 \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/fhir+json"

Points clés :

  • L'URL de base reste la suivante : https://healthlake.us-east-1.amazonaws.com/datastore/abc123

  • Point de terminaison d'interopérabilité inséré : /patientaccess/v2/r4

  • Le chemin de la ressource est inchangé : /Patient/123

  • Les deux appels renvoient des réponses identiques

  • L'appel du terminal d'interopérabilité est automatiquement suivi URIType=patient-access dans CloudWatch

  • Les opérations POST, PUT, PATCH, DELETE fonctionnent de manière identique.

  • Le corps de la demande reste inchangé.

Référence de traduction des terminaux

Endpoint d'interopérabilité Traduit vers Catégorie CMS
baseURL/patientaccess/v2/r4/Patient baseURL/r4/Patient Accès pour les patients
baseURL/​provideraccess/v2/r4/Observation baseURL/r4/Observation Accès du fournisseur
baseURL/payertopayerdx/v2/r4/Practitioner/456 baseURL/r4/Practitioner/456 Data Exchange de payeur à payeur
baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789 baseURL/r4/ExplanationOfBenefit?patient=789 Autorisation préalable

Remarques importantes

  • Aucune différence fonctionnelle : les points de terminaison d'interopérabilité et les points de terminaison FHIR standard renvoient des réponses identiques et prennent en charge des opérations identiques

  • URL de base inchangée : le point de terminaison de votre banque de HealthLake données reste le même

  • Intégration simple : insérez le chemin du point de terminaison d'interopérabilité entre votre URL de base et le type de ressource

  • Suivi automatique : CloudWatch les métriques classent automatiquement les appels par point de terminaison d'interopérabilité utilisé

  • Rétrocompatible : les appels d'API existants sans points de terminaison d'interopérabilité continuent de fonctionner normalement

CloudWatch Mesures améliorées pour la conformité aux CMS

Présentation de

Lorsque vous utilisez les points de terminaison d'interopérabilité du CMS, émet HealthLake automatiquement des CloudWatch métriques améliorées avec des dimensions supplémentaires pour répondre aux exigences de reporting du CMS. Ces mesures permettent de suivre l'utilisation des API par identité de l'appelant, par application et par type d'URI spécifique au CMS, sans qu'aucune configuration supplémentaire ne soit requise.

Comment ça marche

Lorsque vous effectuez un appel d'API à l'aide d'un point de terminaison d'interopérabilité :

# This call...
curl https://healthlake.us-east-1.amazonaws.com/datastore/abc123/patientaccess/v2/r4/Patient/123

# Automatically generates metrics with:
# - URIType: "patient-access"
# - Sub: extracted from your bearer token (SMART on FHIR datastores only)
# - ClientId: extracted from your bearer token (SMART on FHIR datastores only)
# - Plus all standard dimensions (DatastoreId, Operation, etc.)

Aucun code ou configuration supplémentaire n'est nécessaire. Il suffit d'utiliser les points de terminaison d'interopérabilité pour que les métriques améliorées soient automatiquement capturées.

Note

Pour les magasins de données non intelligents sur FHIR, la URIType dimension est toujours capturée, ce qui vous permet de suivre l'utilisation des API par catégorie de CMS. Les ClientId dimensions Sub et ne sont disponibles que lors de l'utilisation de l'authentification SMART sur FHIR avec des jetons au porteur contenant ces allégations.

Nouvelles dimensions métriques

Outre les dimensions existantes (DatastoreId,,Operation)DatastoreType, les dimensions suivantes sont automatiquement ajoutées lors de l'utilisation de points de terminaison d'interopérabilité :

Dimension Description Exemple de valeurs Source
URIType Catégorie de conformité du CMS patient-access, provider-access, payer-to-payer, prior-authorization Déterminé automatiquement à partir du chemin du terminal d'interopérabilité
Sous Identité de l'appelant Identifiant de l'utilisateur/de l'entité Extrait de la réclamation du jeton sub au porteur
ClientId Identifiant de l’application portal_app, ehr_system Extrait de la réclamation du jeton client_id au porteur

Métriques disponibles

Toutes les HealthLake métriques existantes incluent désormais les dimensions supplémentaires lors de l'utilisation de points de terminaison d'interopérabilité :

  • CallCount- Nombre total d'appels d'API

  • Latence : temps de réponse de l'API en millisecondes

  • UserErrors- Nombre de 4xx erreurs client

  • SystemErrors- Nombre de 5xx erreurs de serveur

  • Throttles : nombre de demandes limitées

  • SuccessfulRequests- Nombre d'appels d'API réussis

Interrogation de métriques dans CloudWatch

CloudWatch Exemple de requête Insights

Interrogez tous les appels de l'API Patient Access par application :

SELECT SUM(CallCount)
FROM "AWS/HealthLake"
WHERE DatastoreId = '75c1cf9b0d71cd38fec8f7fb317c4c1a'
    AND URIType = 'patient-access'
GROUP BY ClientId