Funzionalità di conformità CMS - AWS HealthLake
Endpoint di interoperabilità CMSMetriche migliorate CloudWatch per la conformità CMS

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Funzionalità di conformità CMS

AWS HealthLake fornisce funzionalità che consentono di soddisfare i requisiti di interoperabilità e conformità dei CMS (Centers for Medicare & Medicaid Services). Queste funzionalità consentono di tenere traccia dell'utilizzo delle API per categoria CMS e successivamente di riportare le metriche di utilizzo ai fini della conformità.

Endpoint di interoperabilità CMS

Panoramica di

HealthLake fornisce quattro endpoint di interoperabilità CMS che corrispondono alle categorie di API obbligatorie per il CMS. L'URL di base sottostante del tuo data store non cambia. HealthLake Questi endpoint forniscono semplicemente un modo per classificare e tracciare le chiamate API per scopi di reporting CMS.

Scopo

Lo scopo principale di questi endpoint di interoperabilità è consentire ai clienti di:

  • Monitora facilmente le transazioni API per categoria CMS

  • Segnala automaticamente le metriche di utilizzo per la conformità CMS

  • Mantieni i flussi di lavoro FHIR esistenti con modifiche minime

Tutte le chiamate API funzionano allo stesso modo, indipendentemente dal fatto che si utilizzi l'endpoint di interoperabilità o l'endpoint FHIR standard: l'unica differenza è il modo in cui le transazioni sono classificate nelle metriche. CloudWatch

Endpoint di interoperabilità CMS supportati

Categoria CMS Endpoint di interoperabilità Esempio di utilizzo
Accesso per i pazienti /patientaccess/v2/r4 baseURL/patientaccess/v2/r4/Patient/123
Accesso da parte del fornitore /​provideraccess/v2/r4 baseURL/​provideraccess/v2/r4/Observation?patient=123
Da pagante a pagante /payertopayerdx/v2/r4 baseURL/payertopayerdx/v2/r4/Practitioner/456
Servizio di autenticazione precedente /priorauthservice/v2/r4 baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789

Come funzionano gli endpoint di interoperabilità

Chiamata API standard: HealthLake 

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

Con CMS Interoperability Endpoint:

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

Il percorso dell'endpoint di interoperabilità viene semplicemente inserito tra l'URL di base e il tipo di risorsa. Tutto ciò che segue il percorso dell'endpoint di interoperabilità rimane esattamente lo stesso delle chiamate API correnti.

Esempi di utilizzo

Esempio 1: API Patient Access

Chiamata API corrente (funziona ancora):

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"

Con l'endpoint di interoperabilità Patient Access (per il tracciamento 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"

Punti chiave:

  • L'URL di base rimane: https://healthlake.us-east-1.amazonaws.com/datastore/abc123

  • Endpoint di interoperabilità inserito: /patientaccess/v2/r4

  • Percorso delle risorse invariato: /Patient/123

  • Entrambe le chiamate restituiscono risposte identiche

  • La chiamata all'endpoint di interoperabilità viene tracciata automaticamente in URIType=patient-access CloudWatch

  • Le operazioni POST, PUT, PATCH, DELETE funzionano in modo identico.

  • Il corpo della richiesta rimane invariato.

Riferimento alla traduzione degli endpoint

Endpoint di interoperabilità Si traduce in Categoria CMS
baseURL/patientaccess/v2/r4/Patient baseURL/r4/Patient Accesso per i pazienti
baseURL/​provideraccess/v2/r4/Observation baseURL/r4/Observation Accesso da parte del fornitore
baseURL/payertopayerdx/v2/r4/Practitioner/456 baseURL/r4/Practitioner/456 Data Exchange tra pagatori
baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789 baseURL/r4/ExplanationOfBenefit?patient=789 Autorizzazione preventiva

Note importanti

  • Nessuna differenza funzionale: gli endpoint di interoperabilità e gli endpoint FHIR standard restituiscono risposte identiche e supportano operazioni identiche

  • URL di base invariato: l'endpoint del data store rimane lo stesso HealthLake

  • Integrazione semplice: inserisci il percorso dell'endpoint di interoperabilità tra l'URL di base e il tipo di risorsa

  • Tracciamento automatico: le CloudWatch metriche classificano automaticamente le chiamate in base all'endpoint di interoperabilità utilizzato

  • Compatibilità con le versioni precedenti: le chiamate API esistenti senza endpoint di interoperabilità continuano a funzionare normalmente

Metriche migliorate CloudWatch per la conformità CMS

Panoramica di

Quando si utilizzano gli endpoint di interoperabilità CMS, emette HealthLake automaticamente CloudWatch metriche avanzate con dimensioni aggiuntive per supportare i requisiti di reporting CMS. Queste metriche tengono traccia dell'utilizzo dell'API in base all'identità del chiamante, all'applicazione e ai tipi di URI specifici del CMS senza alcuna configurazione aggiuntiva.

Come funziona

Quando effettui una chiamata API utilizzando un endpoint di interoperabilità:

# 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.)

Non è necessario alcun codice o configurazione aggiuntivi. Basta usare gli endpoint di interoperabilità e le metriche avanzate vengono acquisite automaticamente.

Nota

Per gli archivi di dati Non-Smart on FHIR, la URIType dimensione viene comunque acquisita, consentendoti di tracciare l'utilizzo delle API per categoria CMS. ClientIdLe dimensioni Sub and sono disponibili solo quando si utilizza l'autenticazione SMART on FHIR con token portatori contenenti queste attestazioni.

Nuove dimensioni metriche

Oltre alle dimensioni esistenti (DatastoreId,,Operation)DatastoreType, le seguenti dimensioni vengono aggiunte automaticamente quando si utilizzano gli endpoint di interoperabilità:

Dimensione Description Valori di esempio Origine
URIType Categoria di conformità CMS patient-access, provider-access, payer-to-payer, prior-authorization Determinato automaticamente dal percorso dell'endpoint di interoperabilità
Sub Identità del chiamante Identificatore utente/entità Estratto dal token claim del portatore sub
ClientId Identificatore dell'applicazione portal_app, ehr_system Estratto dalla rivendicazione del token al portatore client_id

Metriche disponibili

Tutte le HealthLake metriche esistenti ora includono le dimensioni aggiuntive quando si utilizzano gli endpoint di interoperabilità:

  • CallCount- Numero totale di chiamate API

  • Latenza: tempo di risposta dell'API in millisecondi

  • UserErrors- Numero di 4xx errori del client

  • SystemErrors- Numero di 5xx errori del server

  • Throttles: Numero di richieste limitate

  • SuccessfulRequests- Numero di chiamate API riuscite

Interrogazione delle metriche in CloudWatch

CloudWatch Esempio di query Insights

Interroga tutte le chiamate API Patient Access per applicazione:

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