Recursos de conformidade do CMS - AWS HealthLake
Endpoints de interoperabilidade do CMSCloudWatch Métricas aprimoradas para conformidade com o CMS

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.

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 <token>" \
  -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 <token>" \
  -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. ClientIdAs 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_app, ehr_system Extraído da reivindicação do token do portador client_id

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