Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Características de conformidad con los CMS
AWS HealthLake ofrece funciones que le ayudan a cumplir los requisitos de interoperabilidad y conformidad de los CMS (Centros de Servicios de Medicare y Medicaid). Estas funciones le permiten realizar un seguimiento del uso de las API por categoría de CMS y, posteriormente, elaborar informes sobre las métricas de uso con fines de cumplimiento.
**Topics**
+ [Puntos finales de interoperabilidad de los CMS](#cms-interoperability-endpoints)
+ [CloudWatch Métricas mejoradas para el cumplimiento de los CMS](#cms-cloudwatch-metrics)
## Puntos finales de interoperabilidad de los CMS
### Descripción general de
HealthLake proporciona cuatro puntos finales de interoperabilidad del CMS que corresponden a las categorías de API exigidas por el CMS. La URL base subyacente de su almacén de HealthLake datos no cambia. Estos puntos de enlace simplemente proporcionan una forma de categorizar y realizar un seguimiento de las llamadas a la API con el fin de generar informes sobre los CMS.
### Finalidad
El objetivo principal de estos puntos finales de interoperabilidad es permitir a los clientes:
+ **Realice un seguimiento sencillo de** las transacciones de API por categoría de CMS
+ **Informe automáticamente** las métricas de uso para garantizar el cumplimiento de los CMS
+ **Mantenga** los flujos de trabajo del FHIR existentes con cambios mínimos
Todas las llamadas a la API funcionan de forma idéntica tanto si se utiliza el punto final de interoperabilidad como el punto final estándar del FHIR; la única diferencia es la forma en que se clasifican las transacciones en las métricas. CloudWatch
### Puntos finales de interoperabilidad de CMS compatibles
| Categoría CMS | Punto final de interoperabilidad | Ejemplo de uso |
| --- | --- | --- |
| Acceso de pacientes | /patientaccess/v2/r4 | baseURL/patientaccess/v2/r4/Patient/123 |
| Acceso a proveedores | /provideraccess/v2/r4 | baseURL/provideraccess/v2/r4/Observation?patient=123 |
| De pagador a pagador | /payertopayerdx/v2/r4 | baseURL/payertopayerdx/v2/r4/Practitioner/456 |
| Servicio de autenticación previa | /priorauthservice/v2/r4 | baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789 |
### Cómo funcionan los puntos finales de interoperabilidad
**Llamada a la HealthLake API estándar:**
```
baseURL/resourceType/[id]
baseURL/resourceType?[parameters]
```
**Con CMS Interoperability Endpoint:**
```
baseURL/interoperability-endpoint/resourceType/[id]
baseURL/interoperability-endpoint/resourceType?[parameters]
```
La ruta del punto final de interoperabilidad simplemente se inserta entre la URL base y el tipo de recurso. Todo lo que sigue a la ruta del punto final de interoperabilidad permanece exactamente igual que las llamadas a la API actuales.
### Ejemplos de uso
#### Ejemplo 1: API de acceso para pacientes
**Llamada a la API actual (aún funciona):**
```
curl -X GET \
https://healthlake.us-east-1.amazonaws.com/datastore/abc123/r4/Patient/123 \
-H "Authorization: Bearer " \
-H "Content-Type: application/fhir+json"
```
**Con el punto final de interoperabilidad de Patient Access (para el seguimiento de los CMS):**
```
curl -X GET \
https://healthlake.us-east-1.amazonaws.com/datastore/abc123/patientaccess/v2/r4/Patient/123 \
-H "Authorization: Bearer " \
-H "Content-Type: application/fhir+json"
```
**Puntos clave:**
+ La URL base sigue siendo: `https://healthlake.us-east-1.amazonaws.com/datastore/abc123`
+ Se ha insertado el punto final de interoperabilidad: `/patientaccess/v2/r4`
+ La ruta de recursos no ha cambiado: `/Patient/123`
+ **Ambas llamadas devuelven respuestas idénticas**
+ La llamada al punto final de interoperabilidad se rastrea automáticamente en `URIType=patient-access` CloudWatch
+ Las operaciones POST, PUT, PATCH y DELETE funcionan de forma idéntica.
+ El cuerpo de la solicitud permanece inalterado.
### Referencia de traducción del punto final
| Punto final de interoperabilidad | Se traduce como | Categoría CMS |
| --- | --- | --- |
| baseURL/patientaccess/v2/r4/Patient | baseURL/r4/Patient | Acceso para pacientes |
| baseURL/provideraccess/v2/r4/Observation | baseURL/r4/Observation | Acceso a proveedores |
| baseURL/payertopayerdx/v2/r4/Practitioner/456 | baseURL/r4/Practitioner/456 | Data Exchange de pagador a pagador |
| baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789 | baseURL/r4/ExplanationOfBenefit?patient=789 | Autorización previa |
### Notas importantes
+ **Sin diferencia funcional**: los puntos finales de interoperabilidad y los puntos finales estándar del FHIR arrojan respuestas idénticas y admiten operaciones idénticas
+ **URL base sin cambios**: el punto final de su almacén de HealthLake datos sigue siendo el mismo
+ **Integración sencilla**: inserte la ruta del punto final de interoperabilidad entre la URL base y el tipo de recurso
+ **Seguimiento automático**: CloudWatch las métricas clasifican automáticamente las llamadas según el punto final de interoperabilidad utilizado
+ **Compatible con versiones anteriores**: las llamadas a la API existentes sin puntos de enlace de interoperabilidad siguen funcionando con normalidad
## CloudWatch Métricas mejoradas para el cumplimiento de los CMS
### Descripción general de
Cuando utiliza los puntos finales de interoperabilidad del CMS, emite HealthLake automáticamente CloudWatch métricas mejoradas con dimensiones adicionales para cumplir con los requisitos de presentación de informes de los CMS. **Estas métricas rastrean el uso de la API por identidad de la persona que llama, aplicación y tipos de URI específicos del CMS sin necesidad de realizar ninguna configuración adicional.**
### Funcionamiento
Cuando realizas una llamada a la API mediante un punto final de interoperabilidad:
```
# 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.)
```
**No se necesita ningún código o configuración adicional.** Simplemente utilice los puntos finales de interoperabilidad y las métricas mejoradas se capturarán automáticamente.
**nota**
En el caso de los almacenes de datos del FHIR que no son inteligentes, la `URIType` dimensión se sigue capturando, lo que permite realizar un seguimiento del uso de las API por categoría de CMS. `ClientId`Las dimensiones `Sub` y solo están disponibles cuando se utiliza la autenticación SMART on FHIR con fichas portadoras que contengan estas afirmaciones.
### Nuevas dimensiones métricas
Además de las dimensiones existentes (`DatastoreId`,,`Operation`)`DatastoreType`, las siguientes dimensiones se añaden automáticamente cuando se utilizan puntos finales de interoperabilidad:
| Dimensión | Description (Descripción) | Valores de ejemplo | origen |
| --- | --- | --- | --- |
| URIType | Categoría de conformidad con los CMS | patient-access, provider-access, payer-to-payer, prior-authorization | Se determina automáticamente a partir de la ruta del punto final de interoperabilidad |
| Sub | Identidad de la persona que llama | Identificador de usuario/entidad | Extraído de la afirmación del token del portador sub |
| ClientId | Identificador de la aplicación | portal\$1app, ehr\$1system | Extraído de la afirmación del portador del token client\$1id |
### Métricas disponibles
Todas las HealthLake métricas existentes ahora incluyen las dimensiones adicionales cuando se utilizan los puntos finales de interoperabilidad:
+ **CallCount**- Número total de llamadas a la API
+ **Latencia**: tiempo de respuesta de la API en milisegundos
+ **UserErrors**- Recuento de 4 xx errores de cliente
+ **SystemErrors**- Recuento de 5xx errores en el servidor
+ **Throttles**: número de solicitudes restringidas
+ **SuccessfulRequests**- Número de llamadas a la API que se han realizado correctamente
### Consultando métricas en CloudWatch
#### CloudWatch Ejemplo de consulta de Insights
**Consulta todas las llamadas a la API Patient Access por aplicación:**
```
SELECT SUM(CallCount)
FROM "AWS/HealthLake"
WHERE DatastoreId = '75c1cf9b0d71cd38fec8f7fb317c4c1a'
AND URIType = 'patient-access'
GROUP BY ClientId
```