As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Recursos de conformidade do CMS
AWS HealthLake fornece recursos para ajudá-lo a atender aos requisitos de interoperabilidade e conformidade do CMS (Centers for Medicare & Medicaid Services). Esses recursos permitem que você acompanhe o uso da API por categoria de CMS e, posteriormente, relate as métricas de uso para fins de conformidade.
**Topics**
+ [Endpoints de interoperabilidade do CMS](#cms-interoperability-endpoints)
+ [CloudWatch Métricas aprimoradas para conformidade com o CMS](#cms-cloudwatch-metrics)
## Endpoints de interoperabilidade do CMS
### Visão geral do
HealthLake fornece quatro endpoints de interoperabilidade do CMS que correspondem às categorias de API exigidas pelo CMS. O URL base subjacente do seu armazenamento de HealthLake dados não muda. Esses endpoints simplesmente fornecem uma maneira de categorizar e rastrear suas chamadas de API para fins de geração de relatórios do CMS.
### Finalidade
O objetivo principal desses endpoints de interoperabilidade é permitir que os clientes:
+ **Rastreie facilmente** as transações de API por categoria de CMS
+ **Relate automaticamente** as métricas de uso para conformidade com o CMS
+ **Mantenha** os fluxos de trabalho existentes do FHIR com mudanças mínimas
Todas as chamadas de API funcionam de forma idêntica, independentemente de você usar o endpoint de interoperabilidade ou o endpoint FHIR padrão. A única diferença é como as transações são categorizadas em métricas. CloudWatch
### Endpoints de interoperabilidade CMS compatíveis
| Categoria CMS | Endpoint de interoperabilidade | Exemplo de uso |
| --- | --- | --- |
| Acesso do paciente | /patientaccess/v2/r4 | baseURL/patientaccess/v2/r4/Patient/123 |
| Acesso do provedor | /provideraccess/v2/r4 | baseURL/provideraccess/v2/r4/Observation?patient=123 |
| De jogador para jogador | /payertopayerdx/v2/r4 | baseURL/payertopayerdx/v2/r4/Practitioner/456 |
| Serviço de autenticação prévia | /priorauthservice/v2/r4 | baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789 |
### Como funcionam os endpoints de interoperabilidade
**Chamada HealthLake de API padrão:**
```
baseURL/resourceType/[id]
baseURL/resourceType?[parameters]
```
**Com o CMS Interoperability Endpoint:**
```
baseURL/interoperability-endpoint/resourceType/[id]
baseURL/interoperability-endpoint/resourceType?[parameters]
```
O caminho do endpoint de interoperabilidade é simplesmente inserido entre o URL base e o tipo de recurso. Tudo após o caminho do endpoint de interoperabilidade permanece exatamente igual às suas chamadas de API atuais.
### Exemplos de uso
#### Exemplo 1: API de acesso do paciente
**Chamada de API atual (ainda 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"
```
**Com o endpoint de interoperabilidade Patient Access (para rastreamento de 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"
```
**Pontos-chave:**
+ O URL base permanece: `https://healthlake.us-east-1.amazonaws.com/datastore/abc123`
+ Ponto final de interoperabilidade inserido: `/patientaccess/v2/r4`
+ Caminho do recurso inalterado: `/Patient/123`
+ **Ambas as chamadas retornam respostas idênticas**
+ A chamada do endpoint de interoperabilidade é rastreada automaticamente em `URIType=patient-access` CloudWatch
+ As operações POST, PUT, PATCH, DELETE funcionam de forma idêntica.
+ O corpo da solicitação permanece inalterado.
### Referência de tradução de endpoint
| Endpoint de interoperabilidade | Traduz para | Categoria CMS |
| --- | --- | --- |
| baseURL/patientaccess/v2/r4/Patient | baseURL/r4/Patient | Acesso do paciente |
| baseURL/provideraccess/v2/r4/Observation | baseURL/r4/Observation | Acesso do provedor |
| baseURL/payertopayerdx/v2/r4/Practitioner/456 | baseURL/r4/Practitioner/456 | Troca de Dados de Pagador para Pagador |
| baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789 | baseURL/r4/ExplanationOfBenefit?patient=789 | Autorização prévia |
### Observações importantes
+ **Sem diferença funcional**: os endpoints de interoperabilidade e os endpoints FHIR padrão retornam respostas idênticas e oferecem suporte a operações idênticas
+ **URL base inalterado**: seu endpoint HealthLake de armazenamento de dados permanece o mesmo
+ **Integração simples**: insira o caminho do endpoint de interoperabilidade entre seu URL base e o tipo de recurso
+ **Rastreamento automático**: CloudWatch as métricas categorizam automaticamente as chamadas por endpoint de interoperabilidade usado
+ **Compatível com versões anteriores**: as chamadas de API existentes sem endpoints de interoperabilidade continuam funcionando normalmente
## CloudWatch Métricas aprimoradas para conformidade com o CMS
### Visão geral do
Quando você usa os endpoints de interoperabilidade do CMS, emite HealthLake automaticamente CloudWatch métricas aprimoradas com dimensões adicionais para suportar os requisitos de relatórios do CMS. Essas métricas rastreiam o uso da API por identidade do chamador, aplicativo e tipos de URI específicos do CMS, **sem a necessidade de nenhuma configuração adicional**.
### Como funciona
Quando você faz uma chamada de API usando um endpoint de interoperabilidade:
```
# 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.)
```
**Nenhum código ou configuração adicional é necessário.** Basta usar os endpoints de interoperabilidade e as métricas aprimoradas serão capturadas automaticamente.
**nota**
Para armazenamentos de dados não inteligentes em FHIR, a `URIType` dimensão ainda é capturada, permitindo que você acompanhe o uso da API por categoria de CMS. `ClientId`As dimensões `Sub` e só estão disponíveis ao usar SMART na autenticação FHIR com tokens de portador contendo essas declarações.
### Novas dimensões métricas
Além das dimensões existentes (`DatastoreId`,,`Operation`)`DatastoreType`, as seguintes dimensões são adicionadas automaticamente ao usar endpoints de interoperabilidade:
| Dimensão | Description | Valores de exemplo | Fonte |
| --- | --- | --- | --- |
| URIType | Categoria de conformidade do CMS | patient-access, provider-access, payer-to-payer, prior-authorization | Determinado automaticamente a partir do caminho do endpoint de interoperabilidade |
| Sub | Identidade do chamador | Identificador de usuário/entidade | Extraído da reivindicação do token do portador sub |
| ClientId | Identificador da aplicação | portal\$1app, ehr\$1system | Extraído da reivindicação do token do portador client\$1id |
### Métricas disponíveis
Todas as HealthLake métricas existentes agora incluem as dimensões adicionais ao usar endpoints de interoperabilidade:
+ **CallCount**- Número total de chamadas de API
+ **Latência** - tempo de resposta da API em milissegundos
+ **UserErrors**- Contagem de 4xx erros do cliente
+ **SystemErrors**- Contagem de 5xx erros do servidor
+ **Throttles** - Contagem de solicitações limitadas
+ **SuccessfulRequests**- Contagem de chamadas de API bem-sucedidas
### Consultando métricas em CloudWatch
#### CloudWatch Exemplo de consulta do Insights
**Consulte todas as chamadas da Patient Access API por aplicativo:**
```
SELECT SUM(CallCount)
FROM "AWS/HealthLake"
WHERE DatastoreId = '75c1cf9b0d71cd38fec8f7fb317c4c1a'
AND URIType = 'patient-access'
GROUP BY ClientId
```