CMS-Compliance-Funktionen - AWS HealthLake
Endpunkte der CMS-InteroperabilitätVerbesserte CloudWatch Metriken für die CMS-Konformität

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

CMS-Compliance-Funktionen

AWS HealthLake bietet Funktionen, mit denen Sie die Interoperabilitäts- und Compliance-Anforderungen von CMS (Centers for Medicare & Medicaid Services) erfüllen können. Mit diesen Funktionen können Sie die API-Nutzung nach CMS-Kategorien verfolgen und anschließend Nutzungskennzahlen zu Compliance-Zwecken melden.

Endpunkte der CMS-Interoperabilität

-Übersicht

HealthLake bietet vier CMS-Interoperabilitätsendpunkte, die den vom CMS vorgeschriebenen API-Kategorien entsprechen. Die zugrunde liegende Basis-URL Ihres HealthLake Datenspeichers ändert sich nicht. Diese Endpunkte bieten lediglich eine Möglichkeit, Ihre API-Aufrufe für CMS-Berichtszwecke zu kategorisieren und nachzuverfolgen.

Zweck

Der Hauptzweck dieser Interoperabilitätsendpunkte besteht darin, Kunden Folgendes zu ermöglichen:

  • Einfache Nachverfolgung von API-Transaktionen nach CMS-Kategorien

  • Melden Sie automatisch Nutzungskennzahlen zur Einhaltung der CMS-Vorschriften

  • Behalten Sie bestehende FHIR-Workflows mit minimalen Änderungen bei

Alle API-Aufrufe funktionieren identisch, unabhängig davon, ob Sie den Interoperabilitäts-Endpunkt oder den Standard-FHIR-Endpunkt verwenden. Der einzige Unterschied besteht darin, wie die Transaktionen in Metriken kategorisiert werden. CloudWatch

Unterstützte CMS-Interoperabilitätsendpunkte

CMS-Kategorie Interoperabilitäts- Beispielverwendung
Zugang für Patienten /patientaccess/v2/r4 baseURL/patientaccess/v2/r4/Patient/123
Zugang zum Anbieter /​provideraccess/v2/r4 baseURL/​provideraccess/v2/r4/Observation?patient=123
Zahler zu Zahler /payertopayerdx/v2/r4 baseURL/payertopayerdx/v2/r4/Practitioner/456
Vorheriger Authentifizierungsdienst /priorauthservice/v2/r4 baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789

Wie funktionieren Interoperabilitätsendpunkte

HealthLake Standard-API-Aufruf:

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

Mit CMS-Interoperabilitätsendpunkt:

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

Der Pfad zum Interoperabilitätsendpunkt wird einfach zwischen Ihrer Basis-URL und dem Ressourcentyp eingefügt. Alles, was hinter dem Pfad zum Interoperabilitätsendpunkt steht, bleibt genau so wie bei Ihren aktuellen API-Aufrufen.

Verwendungsbeispiele

Beispiel 1: API für den Patientenzugriff

Aktueller API-Aufruf (funktioniert immer noch):

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"

Mit dem Interoperabilitätsendpunkt Patient Access (für CMS-Tracking):

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"

Die wichtigsten Punkte:

  • Die Basis-URL bleibt bestehen: https://healthlake.us-east-1.amazonaws.com/datastore/abc123

  • Interoperabilitäts-Endpunkt eingefügt: /patientaccess/v2/r4

  • Ressourcenpfad unverändert: /Patient/123

  • Beide Anrufe geben identische Antworten zurück

  • Der Anruf am Interoperabilitäts-Endpunkt wird automatisch unter URIType=patient-access in nachverfolgt CloudWatch

  • Die Operationen POST, PUT, PATCH und DELETE funktionieren identisch.

  • Der Text der Anfrage bleibt unverändert.

Referenz zur Endpunkt-Übersetzung

Interoperabilitäts- Übersetzt in CMS-Kategorie
baseURL/patientaccess/v2/r4/Patient baseURL/r4/Patient Zugang für Patienten
baseURL/​provideraccess/v2/r4/Observation baseURL/r4/Observation Zugang zum Anbieter
baseURL/payertopayerdx/v2/r4/Practitioner/456 baseURL/r4/Practitioner/456 Data Exchange von Zahler zu Zahler
baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789 baseURL/r4/ExplanationOfBenefit?patient=789 Vorherige Autorisierung

Wichtige Hinweise

  • Kein funktionaler Unterschied: Interoperabilitätsendpunkte und Standard-FHIR-Endpunkte geben identische Antworten zurück und unterstützen identische Operationen

  • Unveränderte Basis-URL: Ihr HealthLake Datenspeicher-Endpunkt bleibt derselbe

  • Einfache Integration: Fügen Sie den Pfad zum Interoperabilitäts-Endpunkt zwischen Ihrer Basis-URL und dem Ressourcentyp ein

  • Automatisches Tracking: Die CloudWatch Metriken kategorisieren Anrufe automatisch nach dem verwendeten Interoperabilitätsendpunkt

  • Abwärtskompatibel: Bestehende API-Aufrufe ohne Interoperabilitätsendpunkte funktionieren weiterhin normal

Verbesserte CloudWatch Metriken für die CMS-Konformität

-Übersicht

Wenn Sie die CMS-Interoperabilitätsendpunkte verwenden, HealthLake werden automatisch erweiterte CloudWatch Messwerte mit zusätzlichen Dimensionen ausgegeben, um die CMS-Berichtsanforderungen zu erfüllen. Diese Metriken verfolgen die API-Nutzung nach Anruferidentität, Anwendung und CMS-spezifischen URI-Typen, ohne dass eine zusätzliche Konfiguration erforderlich ist.

Funktionsweise

Wenn Sie einen API-Aufruf über einen Interoperabilitäts-Endpunkt tätigen:

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

Es ist kein zusätzlicher Code oder eine zusätzliche Konfiguration erforderlich. Verwenden Sie einfach die Interoperabilitätsendpunkte, und die erweiterten Metriken werden automatisch erfasst.

Anmerkung

Bei Datenspeichern ohne SMART on FHIR wird die URIType Dimension trotzdem erfasst, sodass Sie die API-Nutzung nach CMS-Kategorien verfolgen können. Die ClientId Dimensionen Sub und sind nur verfügbar, wenn SMART für die FHIR-Authentifizierung mit Inhaber-Tokens verwendet wird, die diese Ansprüche enthalten.

Neue metrische Dimensionen

Zusätzlich zu den vorhandenen Dimensionen (DatastoreId,DatastoreType,Operation) werden die folgenden Dimensionen automatisch hinzugefügt, wenn Interoperabilitätsendpunkte verwendet werden:

Dimension Description Beispielwerte Quelle
URIType CMS-Konformitätskategorie patient-access, provider-access, payer-to-payer, prior-authorization Wird automatisch anhand des Interoperabilitäts-Endpunktpfads
Sub Identität des Anrufers Benutzer-/Entitäts-ID Aus dem Inhaber-Token-Anspruch extrahiert sub
ClientId Anwendungs-Identifikator portal_app, ehr_system Aus dem Inhaber-Token-Anspruch extrahiert client_id

Verfügbare Metriken

Alle vorhandenen HealthLake Metriken enthalten jetzt die zusätzlichen Dimensionen bei der Verwendung von Interoperabilitätsendpunkten:

  • CallCount- Gesamtzahl der API-Aufrufe

  • Latenz — API-Antwortzeit in Millisekunden

  • UserErrors- Anzahl der 4xx-Client-Fehler

  • SystemErrors- Anzahl der 5xx Serverfehler

  • Drosseln — Anzahl der gedrosselten Anfragen

  • SuccessfulRequests- Anzahl der erfolgreichen API-Aufrufe

Abfragen von Metriken in CloudWatch

CloudWatch Beispiel für eine Insights-Abfrage

Alle API-Aufrufe für den Patientenzugriff nach Anwendung abfragen:

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