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á.
# AWS HealthLake referência
O seguinte material de referência de apoio está disponível para SMART em FHIR, FHIR e. AWS HealthLake
**nota**
Todas as HealthLake ações e tipos de dados nativos são descritos em uma referência separada. Para obter mais informações, consulte a [https://docs.aws.amazon.com/healthlake/latest/APIReference/](https://docs.aws.amazon.com/healthlake/latest/APIReference/).
**Topics**
+ [SMART em FHIR](reference-smart-on-fhir.md)
+ [PARA R4](reference-fhir.md)
+ [Compliance](reference-compliance.md)
+ [HealthLake](reference-healthlake.md)
# SMART no suporte FHIR para AWS HealthLake
Um armazenamento de HealthLake dados habilitado para aplicações médicas substituíveis e tecnologias reutilizáveis (SMART) permite o acesso ao SMART em aplicativos compatíveis com FHIR. HealthLake os dados são acessados por meio da autenticação e autorização de solicitações usando um servidor de autorização terceirizado. Portanto, em vez de gerenciar as credenciais do usuário via AWS Identity and Access Management, você está fazendo isso usando um SMART no servidor de autorização compatível com FHIR.
**nota**
HealthLake suporta SMART nas versões 1.0 e 2.0 do FHIR. Para saber mais sobre essas estruturas, consulte [SMART App Launch na documentação](https://www.hl7.org/fhir/smart-app-launch/) do *FHIR R4*.
HealthLake os armazenamentos de dados oferecem suporte às seguintes estruturas de autenticação e autorização para SMART em solicitações FHIR:
**OpenID (AuthN)**: para autenticar a pessoa ou o aplicativo do cliente é quem (ou o que) ela afirma ser.
**OAuth 2.0 (AuthZ)**: para autorizar em quais recursos FHIR em seu armazenamento de HealthLake dados uma solicitação autenticada pode ler ou gravar. Isso é definido pelos escopos configurados em seu servidor de autorização.
Você pode criar um SMART no armazenamento de dados habilitado para FHIR usando o AWS CLI ou. AWS SDKs Para obter mais informações, consulte [Criando um armazenamento HealthLake de dados](managing-data-stores-create.md).
**Topics**
+ [Começando a usar o SMART no FHIR](reference-smart-on-fhir-getting-started.md)
+ [HealthLake requisitos de autenticação para SMART no FHIR](reference-smart-on-fhir-authentication.md)
+ [SMART em escopos FHIR OAuth 2.0 suportados por HealthLake](reference-smart-on-fhir-oauth-scopes.md)
+ [Validação de token usando AWS Lambda](reference-smart-on-fhir-token-validation.md)
+ [Usando autorização refinada com um SMART no armazenamento de dados habilitado para FHIR HealthLake](reference-smart-on-fhir-fine-grained-authorization.md)
+ [Buscando o SMART no documento FHIR Discovery](reference-smart-on-fhir-discovery-document.md)
+ [Fazendo uma solicitação da API FHIR REST em um armazenamento de dados habilitado para Smart HealthLake](reference-smart-on-fhir-request-example.md)
# Começando a usar o SMART no FHIR
Os tópicos a seguir descrevem como começar a usar o SMART na autorização FHIR para. AWS HealthLake Eles incluem os recursos que você deve provisionar em sua AWS conta, a criação de um armazenamento de HealthLake dados habilitado para SMART on FHIR e um exemplo de como um aplicativo cliente SMART on FHIR interage com um servidor de autorização e um armazenamento de dados. HealthLake
**Topics**
+ [Configurando recursos para SMART no FHIR](#smart-on-fhir-resources)
+ [Fluxo de trabalho do aplicativo cliente para SMART no FHIR](#smart-on-fhir-client-app-workflow)
## Configurando recursos para SMART no FHIR
As etapas a seguir definem como as solicitações SMART on FHIR são tratadas HealthLake e os recursos necessários para que elas tenham sucesso. Os elementos a seguir funcionam juntos em um fluxo de trabalho para criar uma solicitação SMART na FHIR:
+ **O usuário final**: geralmente, um paciente ou médico que usa um aplicativo SMART on FHIR de terceiros para acessar dados em um armazenamento de dados. HealthLake
+ **O aplicativo SMART on FHIR (conhecido como aplicativo cliente)**: um aplicativo que deseja acessar dados encontrados no armazenamento de HealthLake dados.
+ **O servidor de autorização**: um servidor compatível com o OpenID Connect que é capaz de autenticar usuários e emitir tokens de acesso.
+ **O armazenamento de HealthLake dados**: um armazenamento de HealthLake dados habilitado para SMART on FHIR que usa uma função Lambda para responder às solicitações REST do FHIR que fornecem um token portador.
Para que esses elementos funcionem juntos, você deve criar os seguintes recursos.
**nota**
[Recomendamos criar seu SMART no armazenamento de HealthLake dados habilitado para FHIR depois de configurar o servidor de autorização, definir os [escopos](reference-smart-on-fhir-oauth-scopes.md) necessários nele e criar uma AWS Lambda função para lidar com a introspecção de tokens.](reference-smart-on-fhir-token-validation.md)
**1. Configurar um endpoint do servidor de autorização**
Para usar o SMART na estrutura FHIR, você precisa configurar um servidor de autorização terceirizado que possa validar as solicitações REST do FHIR feitas em um armazenamento de dados. Para obter mais informações, consulte [HealthLake requisitos de autenticação para SMART no FHIR](reference-smart-on-fhir-authentication.md).
**2. Defina escopos em seu servidor de autorização para controlar os níveis de acesso ao armazenamento de HealthLake dados**
A estrutura SMART on FHIR usa OAuth escopos para determinar a quais recursos FHIR uma solicitação autenticada tem acesso e em que medida. Definir escopos é uma forma de projetar com o mínimo de privilégios. Para obter mais informações, consulte [SMART em escopos FHIR OAuth 2.0 suportados por HealthLake](reference-smart-on-fhir-oauth-scopes.md).
**3. Configure uma AWS Lambda função capaz de realizar a introspecção de tokens**
Uma solicitação FHIR REST enviada pelo aplicativo cliente em um SMART no armazenamento de dados habilitado para FHIR contém um JSON Web Token (JWT). Para obter mais informações, consulte [Decodificando um JWT](reference-smart-on-fhir-token-validation.md).
**4. Crie um SMART no armazenamento de dados habilitado HealthLake para FHIR**
Para criar um SMART no armazenamento de HealthLake dados FHIR, você precisa fornecer um. `IdentityProviderConfiguration` Para obter mais informações, consulte [Criando um armazenamento HealthLake de dados](managing-data-stores-create.md).
## Fluxo de trabalho do aplicativo cliente para SMART no FHIR
A seção a seguir explica como iniciar um aplicativo cliente e fazer uma solicitação FHIR REST bem-sucedida em um armazenamento de HealthLake dados dentro do contexto do SMART no FHIR.
**1. Faça uma `GET` solicitação ao Known Uniform Resource Identifier usando o aplicativo cliente**
Um aplicativo cliente habilitado para SMART deve fazer uma `GET` solicitação para encontrar os endpoints de autorização do seu armazenamento de HealthLake dados. Isso é feito por meio de uma solicitação de Identificador Uniforme de Recursos (URI) conhecido. Para obter mais informações, consulte [Buscando o SMART no documento FHIR Discovery](reference-smart-on-fhir-discovery-document.md).
**2. Solicitar acesso e escopos**
O aplicativo cliente usa o ponto final de autorização do servidor de autorização, para que o usuário possa fazer login. Esse processo autentica o usuário. Os escopos são usados para definir quais recursos FHIR em seu armazenamento de HealthLake dados um aplicativo cliente pode acessar. Para obter mais informações, consulte [SMART em escopos FHIR OAuth 2.0 suportados por HealthLake](reference-smart-on-fhir-oauth-scopes.md).
**3. Tokens de acesso**
Agora que o usuário foi autenticado, um aplicativo cliente recebe um token de acesso JWT do servidor de autorização. Esse token é fornecido quando o aplicativo cliente envia uma solicitação FHIR REST para o. HealthLake Para obter mais informações, consulte [Validação de token](reference-smart-on-fhir-token-validation.md).
**4. Faça uma solicitação da API REST FHIR no SMART no armazenamento de dados habilitado para FHIR HealthLake**
Agora, o aplicativo cliente pode enviar uma solicitação da API FHIR REST para um endpoint de armazenamento de HealthLake dados usando o token de acesso fornecido pelo servidor de autorização. Para obter mais informações, consulte [Fazendo uma solicitação da API FHIR REST em um armazenamento de dados habilitado para Smart HealthLake](reference-smart-on-fhir-request-example.md).
**5. Valide o token de acesso JWT**
Para validar o token de acesso enviado na solicitação FHIR REST, use uma função Lambda. Para obter mais informações, consulte [Validação de token usando AWS Lambda](reference-smart-on-fhir-token-validation.md).
# HealthLake requisitos de autenticação para SMART no FHIR
Para acessar recursos do FHIR em um SMART no armazenamento de HealthLake dados habilitado para FHIR, um aplicativo cliente deve ser autorizado por um servidor de autorização OAuth compatível com 2.0 e apresentar um token de OAuth portador como parte de uma solicitação da API FHIR REST. Para encontrar o endpoint do servidor de autorização, use o documento de descoberta HealthLake SMART on FHIR por meio de um identificador `Well-Known` uniforme de recursos. Para saber mais sobre esse processo, consulte [Buscando o SMART no documento FHIR Discovery](reference-smart-on-fhir-discovery-document.md).
Ao criar um SMART no armazenamento de HealthLake dados FHIR, você deve definir o ponto final do servidor de autorização e o ponto final do token no `metadata` elemento da solicitação. `CreateFHIRDatastore` Para saber mais sobre como definir o `metadata` elemento, consulte[Criando um armazenamento HealthLake de dados](managing-data-stores-create.md).
Usando os endpoints do servidor de autorização, o aplicativo cliente autenticará um usuário com o serviço de autorização. Depois de autorizado e autenticado, um JSON Web Token (JWT) é gerado pelo serviço de autorização e passado para o aplicativo cliente. Esse token contém escopos de recursos FHIR que o aplicativo cliente pode usar, o que, por sua vez, restringe quais dados o usuário pode acessar. Opcionalmente, se o escopo de lançamento foi fornecido, a resposta conterá esses detalhes. Para saber mais sobre o SMART em escopos FHIR suportados por HealthLake, consulte. [SMART em escopos FHIR OAuth 2.0 suportados por HealthLake](reference-smart-on-fhir-oauth-scopes.md)
Usando o JWT concedido pelo servidor de autorização, um aplicativo cliente faz chamadas da API FHIR REST para um SMART no armazenamento de dados habilitado para FHIR. HealthLake Para validar e decodificar o JWT, você precisa criar uma função Lambda. HealthLake invoca essa função Lambda em seu nome quando uma solicitação da API FHIR REST é recebida. Para ver um exemplo de função Lambda inicial, consulte. [Validação de token usando AWS Lambda](reference-smart-on-fhir-token-validation.md)
## Elementos do servidor de autorização necessários para criar um SMART no armazenamento de dados habilitado HealthLake para FHIR
Na `CreateFHIRDatastore` solicitação, você precisa fornecer o endpoint de autorização e o endpoint do token como parte do `metadata` elemento no `IdentityProviderConfiguration` objeto. Tanto o endpoint de autorização quanto o endpoint do token são obrigatórios. Para ver um exemplo de como isso é especificado na `CreateFHIRDatastore` solicitação, consulte[Criando um armazenamento HealthLake de dados](managing-data-stores-create.md).
## Declarações necessárias para concluir uma solicitação da API REST FHIR em um SMART no armazenamento de dados habilitado para FHIR HealthLake
Sua AWS Lambda função deve conter as seguintes declarações para que seja uma solicitação válida da API FHIR REST em um armazenamento de dados SMART no FHIR ativado. HealthLake
+ `nbf`: Reivindicação [(não anterior) — A reclamação](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.5) “nbf” (não antes) identifica o momento antes do qual o JWT NÃO DEVE ser aceito para processamento. O processamento da reclamação “nbf” exige que a atual date/time DEVE ser posterior ou igual à não date/time listada antes na reivindicação “nbf”. O exemplo da função Lambda que fornecemos é convertido `iat` da resposta do servidor em. `nbf`
+ `exp`: [(Tempo de expiração) — A reivindicação](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4) “exp” (prazo de expiração) identifica o prazo de expiração a partir do qual o JWT não deve ser aceito para processamento.
+ `isAuthorized`: Um booleano definido como. `True` Indica que a solicitação foi autorizada no servidor de autorização.
+ `aud`: Reivindicação [(Audiência) — A afirmação](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3) “aud” (audiência) identifica os destinatários aos quais o JWT se destina. Deve ser um terminal de armazenamento de HealthLake dados SMART no FHIR habilitado.
+ `scope`: deve ser pelo menos um escopo relacionado a um recurso do FHIR. Esse escopo é definido em seu servidor de autorização. Para saber mais sobre os escopos relacionados a recursos do FHIR aceitos por HealthLake, consulte. [SMART nos escopos de recursos do FHIR para HealthLake](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest)
# SMART em escopos FHIR OAuth 2.0 suportados por HealthLake
HealthLake usa OAuth 2.0 como protocolo de autorização. O uso desse protocolo em seu servidor de autorização permite definir permissões de armazenamento de HealthLake dados (criar, ler, atualizar, excluir e pesquisar) para recursos FHIR aos quais um aplicativo cliente tem acesso.
A estrutura SMART on FHIR define um conjunto de escopos que podem ser solicitados do servidor de autorização. Por exemplo, um aplicativo cliente projetado apenas para permitir que os pacientes visualizem seus resultados laboratoriais ou visualizem seus detalhes de contato só deve ser *autorizado* a solicitar `read` escopos.
**nota**
HealthLake fornece suporte para SMART no FHIR V1 e V2, conforme descrito abaixo. O SMART no FHIR [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html#HealthLake-Type-IdentityProviderConfiguration-AuthorizationStrategy](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html#HealthLake-Type-IdentityProviderConfiguration-AuthorizationStrategy)é definido para um dos três valores a seguir quando seu armazenamento de dados é criado:
`SMART_ON_FHIR_V1`— Support somente para SMART no FHIR V1, que inclui permissões `read` (leitura/pesquisa) e (). `write` create/update/delete
`SMART_ON_FHIR`— Support para SMART no FHIR V1 e V2, que inclui,`create`, `read``update`, `delete` e permissões. `search`
`AWS_AUTH`— A estratégia de AWS HealthLake autorização padrão; não afiliada à SMART no FHIR.
## Escopo de lançamento independente
HealthLake suporta o escopo `launch/patient` do modo de inicialização autônomo.
No modo de inicialização autônomo, um aplicativo cliente solicita acesso aos dados clínicos do paciente porque o usuário e o paciente não são conhecidos pelo aplicativo cliente. Assim, a solicitação de autorização do aplicativo do cliente solicita explicitamente que o escopo do paciente seja devolvido. Após a autenticação bem-sucedida, o servidor de autorização emite um token de acesso contendo o escopo do paciente de lançamento solicitado. O contexto necessário do paciente é fornecido junto com o token de acesso na resposta do servidor de autorização.
**Escopos do modo de lançamento suportados**
| Escopo | Description |
| --- | --- |
| `launch/patient` | Um parâmetro em uma solicitação de autorização OAuth 2.0 solicitando que os dados do paciente sejam retornados na resposta de autorização. |
## SMART nos escopos de recursos do FHIR para HealthLake
HealthLake define três níveis de SMART nos escopos de recursos do FHIR.
+ `patient`os escopos concedem acesso a dados específicos sobre um único paciente.
+ `user`os escopos concedem acesso a dados específicos que um usuário pode acessar.
+ `system`os escopos concedem acesso a todos os recursos do FHIR encontrados no armazenamento de dados. HealthLake
As seções a seguir listam a sintaxe para construir escopos de recursos FHIR usando SMART no FHIR V1 ou SMART no FHIR V2.
**nota**
A estratégia de autorização SMART on FHIR é definida quando seu armazenamento de dados é criado. Para obter mais informações, consulte [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html#HealthLake-Type-IdentityProviderConfiguration-AuthorizationStrategy](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html#HealthLake-Type-IdentityProviderConfiguration-AuthorizationStrategy) na *Referência de APIs do AWS HealthLake *.
### SMART em escopos FHIR V1 suportados por HealthLake
Ao usar o SMART no FHIR V1, a sintaxe geral para construir escopos de recursos do FHIR é a seguinte. HealthLake Para ver todo o caminho do URL no exemplo a seguir, role até o botão **Copiar**.
```
('patient' | 'user' | 'system') '/' (fhir-resource | '*') '.' ('read' | 'write' | '*')
```
**SMART em escopos de autorização compatíveis com FHIR v1**
| Sintaxe do escopo | Exemplo de escopo | Resultado |
| --- | --- | --- |
| `patient/(fhir-resource \| '*').('read' \| 'write' \| '*')` | patient/AllergyIntolerance.\$1 | O aplicativo cliente do paciente tem acesso de leitura/gravação em nível de instância a todas as alergias registradas. |
| `user/(fhir-resource \| '*').('read' \| 'write' \| '*')` | user/Observation.read | O aplicativo cliente do usuário tem read/write acesso em nível de instância a todas as observações registradas. |
| system/('read' \$1 'write' \$1 \$1) | system/\$1.\$1 | O aplicativo cliente do sistema tem read/write acesso a todos os dados de recursos do FHIR. |
### SMART em escopos FHIR V2 suportados por HealthLake
Ao usar o SMART no FHIR V2, a sintaxe geral para construir escopos de recursos do FHIR é a seguinte. HealthLake Para ver todo o caminho do URL no exemplo a seguir, role até o botão **Copiar**.
```
('patient' | 'user' | 'system') '/' (fhir-resource | '*') '.' ('c' | 'r' | 'u' | 'd' | 's')
```
**nota**
Para usar o SMART no FHIR V2, você deve passar o valor [https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#permissions](https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#permissions)para a `capabilities` string de metadados, que é um membro do tipo de dados. [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)
HealthLake suporta escopos granulares. Para obter mais informações, consulte os [escopos granulares compatíveis](https://hl7.org/fhir/us/core/scopes.html#the-following-granular-scopes-shall-be-supported) no *FHIR US* Core Implementation Guide.
**SMART em escopos de autorização compatíveis com FHIR V2**
| Sintaxe do escopo | Exemplo de escopo V1 | Resultado |
| --- | --- | --- |
| `patient/Observation.rs` | user/Observation.read | Permissão para ler e pesquisar Observation recursos para o paciente atual. |
| `system/*.cruds` | system/\$1.\$1 | O aplicativo cliente do sistema tem create/read/update/delete/search acesso total a todos os dados de recursos do FHIR. |
# Validação de token usando AWS Lambda
Ao criar um HealthLake SMART no armazenamento de dados habilitado para FHIR, você deve fornecer o ARN da AWS Lambda função na solicitação. `CreateFHIRDatastore` O ARN da função Lambda é especificado no `IdentityProviderConfiguration` objeto usando o parâmetro. `IdpLambdaArn`
Você deve criar a função Lambda antes de criar seu SMART no armazenamento de dados habilitado para FHIR. Depois de criar o armazenamento de dados, o ARN do Lambda não pode ser alterado. Para ver o ARN do Lambda que você especificou quando o armazenamento de dados foi criado, use a ação da API. `DescribeFHIRDatastore`
**Para que uma solicitação FHIR REST seja bem-sucedida em um armazenamento de dados SMART no FHIR ativado, sua função Lambda deve fazer o seguinte:**
+ Retorne uma resposta em menos de 1 segundo para o endpoint do armazenamento de HealthLake dados.
+ Decodifique o token de acesso fornecido no cabeçalho de autorização da solicitação da API REST enviada pelo aplicativo cliente.
+ Atribua uma função de serviço do IAM que tenha permissões suficientes para realizar a solicitação da API FHIR REST.
+ As declarações a seguir são necessárias para concluir uma solicitação da API FHIR REST. Para saber mais, consulte [Declarações necessárias](reference-smart-on-fhir-authentication.md#server-response).
+ `nbf`
+ `exp`
+ `isAuthorized`
+ `aud`
+ `scope`
Ao trabalhar com o Lambda, você precisa criar uma função de execução e uma política baseada em recursos, além da sua função Lambda. A função de execução de uma função do Lambda é uma função do IAM que concede à função permissão para acessar os serviços e recursos da AWS necessários em tempo de execução. A política baseada em recursos que você fornece deve permitir HealthLake invocar sua função em seu nome.
As seções deste tópico descrevem um exemplo de solicitação de um aplicativo cliente e uma resposta decodificada, as etapas necessárias para criar uma função AWS Lambda e como criar uma política baseada em recursos que possa assumir. HealthLake
+ [Parte 1: Criando uma função Lambda](#smart-on-fhir-lambda-create)
+ [Parte 2: Criando uma função HealthLake de serviço usada pela função AWS Lambda](#smart-on-fhir-lambda-service-role)
+ [Parte 3: Atualizando a função de execução da função Lambda](#smart-on-fhir-lambda-service-role-execution-role)
+ [Parte 4: Adicionando uma política de recursos à sua função Lambda](#smart-on-fhir-lambda-invoke-healthlake)
+ [Parte 5: Provisionando a simultaneidade para sua função Lambda](#smart-on-fhir-lambda-function-scaling)
## Criação de uma função AWS Lambda
A função Lambda criada neste tópico é acionada quando HealthLake recebe uma solicitação para um SMART no armazenamento de dados habilitado para FHIR. A solicitação do aplicativo cliente contém uma chamada à API REST e um cabeçalho de autorização contendo um token de acesso.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
Authorization: Bearer i8hweunweunweofiwweoijewiwe
```
O exemplo da função Lambda neste tópico é usado AWS Secrets Manager para obscurecer as credenciais relacionadas ao servidor de autorização. É altamente recomendável não fornecer detalhes de login do servidor de autorização diretamente em uma função Lambda.
**Example validando uma solicitação FHIR REST contendo um token do portador da autorização**
O exemplo da função Lambda mostra como validar uma solicitação FHIR REST enviada para um SMART no armazenamento de dados habilitado para FHIR. Para ver step-by-steps instruções sobre como implementar essa função Lambda, consulte. [Criando uma função Lambda usando o Console de gerenciamento da AWS](#create-lambda-console)
Se a solicitação da API FHIR REST não contiver um endpoint de armazenamento de dados, token de acesso e operação REST válidos, a função Lambda falhará. Para saber mais sobre os elementos necessários do servidor de autorização, consulte[Declarações necessárias](reference-smart-on-fhir-authentication.md#server-response).
```
import base64
import boto3
import logging
import json
import os
from urllib import request, parse
logger = logging.getLogger()
logger.setLevel(logging.INFO)
## Uses Secrets manager to gain access to the access key ID and secret access key for the authorization server
client = boto3.client('secretsmanager', region_name="region-of-datastore")
response = client.get_secret_value(SecretId='name-specified-by-customer-in-secretsmanager')
secret = json.loads(response['SecretString'])
client_id = secret['client_id']
client_secret = secret['client_secret']
unencoded_auth = f'{client_id}:{client_secret}'
headers = {
'Authorization': f'Basic {base64.b64encode(unencoded_auth.encode()).decode()}',
'Content-Type': 'application/x-www-form-urlencoded'
}
auth_endpoint = os.environ['auth-server-base-url'] # Base URL of the Authorization server
user_role_arn = os.environ['iam-role-arn'] # The IAM role client application will use to complete the HTTP request on the datastore
def lambda_handler(event, context):
if 'datastoreEndpoint' not in event or 'operationName' not in event or 'bearerToken' not in event:
return {}
datastore_endpoint = event['datastoreEndpoint']
operation_name = event['operationName']
bearer_token = event['bearerToken']
logger.info('Datastore Endpoint [{}], Operation Name: [{}]'.format(datastore_endpoint, operation_name))
## To validate the token
auth_response = auth_with_provider(bearer_token)
logger.info('Auth response: [{}]'.format(auth_response))
auth_payload = json.loads(auth_response)
## Required parameters needed to be sent to the datastore endpoint for the HTTP request to go through
auth_payload["isAuthorized"] = bool(auth_payload["active"])
auth_payload["nbf"] = auth_payload["iat"]
return {"authPayload": auth_payload, "iamRoleARN": user_role_arn}
## access the server
def auth_with_provider(token):
data = {'token': token, 'token_type_hint': 'access_token'}
req = request.Request(url=auth_endpoint + '/v1/introspect', data=parse.urlencode(data).encode(), headers=headers)
with request.urlopen(req) as resp:
return resp.read().decode()
```
### Criando uma função Lambda usando o Console de gerenciamento da AWS
O procedimento a seguir pressupõe que você já tenha criado a função de serviço que deseja assumir HealthLake ao lidar com uma solicitação da API REST FHIR em um armazenamento de dados SMART no FHIR habilitado. Se você não criou a função de serviço, ainda pode criar a função Lambda. Você deve adicionar o ARN da função de serviço antes que a função Lambda funcione. Para saber mais sobre como criar uma função de serviço e especificá-la na função Lambda, consulte [Criação de uma função HealthLake de serviço para uso na função AWS Lambda usada para decodificar um JWT](#smart-on-fhir-lambda-service-role)
**Para criar uma função Lambda ()Console de gerenciamento da AWS**
1. Abra a [página Funções](https://console.aws.amazon.com/lambda/home/functions) do console do Lambda.
1. Escolha a opção **Criar função**.
1. Selecione **Criar do zero**.
1. Em **Informações básicas**, insira um **nome de função**. Em **Tempo de execução**, escolha um tempo de execução baseado em python.
1. Em **Execution role** (Perfil de execução), escolha **Create a new role with basic Lambda permissions** (Criar um novo perfil com as permissões básicas do Lambda).
O Lambda cria uma [função de execução](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) que concede à função permissão para fazer upload de registros para a Amazon. CloudWatch A função Lambda assume a função de execução quando você invoca sua função e usa a função de execução para criar credenciais para o SDK. AWS
1. Escolha a guia **Código** e adicione o exemplo da função Lambda.
Se você ainda não criou a função de serviço para usar a função Lambda, precisará criá-la antes que a função de amostra do Lambda funcione. Para saber mais sobre a criação de uma função de serviço para a função Lambda, consulte. [Criação de uma função HealthLake de serviço para uso na função AWS Lambda usada para decodificar um JWT](#smart-on-fhir-lambda-service-role)
```
import base64
import boto3
import logging
import json
import os
from urllib import request, parse
logger = logging.getLogger()
logger.setLevel(logging.INFO)
## Uses Secrets manager to gain access to the access key ID and secret access key for the authorization server
client = boto3.client('secretsmanager', region_name="region-of-datastore")
response = client.get_secret_value(SecretId='name-specified-by-customer-in-secretsmanager')
secret = json.loads(response['SecretString'])
client_id = secret['client_id']
client_secret = secret['client_secret']
unencoded_auth = f'{client_id}:{client_secret}'
headers = {
'Authorization': f'Basic {base64.b64encode(unencoded_auth.encode()).decode()}',
'Content-Type': 'application/x-www-form-urlencoded'
}
auth_endpoint = os.environ['auth-server-base-url'] # Base URL of the Authorization server
user_role_arn = os.environ['iam-role-arn'] # The IAM role client application will use to complete the HTTP request on the datastore
def lambda_handler(event, context):
if 'datastoreEndpoint' not in event or 'operationName' not in event or 'bearerToken' not in event:
return {}
datastore_endpoint = event['datastoreEndpoint']
operation_name = event['operationName']
bearer_token = event['bearerToken']
logger.info('Datastore Endpoint [{}], Operation Name: [{}]'.format(datastore_endpoint, operation_name))
## To validate the token
auth_response = auth_with_provider(bearer_token)
logger.info('Auth response: [{}]'.format(auth_response))
auth_payload = json.loads(auth_response)
## Required parameters needed to be sent to the datastore endpoint for the HTTP request to go through
auth_payload["isAuthorized"] = bool(auth_payload["active"])
auth_payload["nbf"] = auth_payload["iat"]
return {"authPayload": auth_payload, "iamRoleARN": user_role_arn}
## Access the server
def auth_with_provider(token):
data = {'token': token, 'token_type_hint': 'access_token'}
req = request.Request(url=auth_endpoint + '/v1/introspect', data=parse.urlencode(data).encode(), headers=headers)
with request.urlopen(req) as resp:
return resp.read().decode()
```
### Modificando a função de execução de uma função Lambda
Depois de criar a função Lambda, você precisa atualizar a função de execução para incluir as permissões necessárias para chamar o Secrets Manager. No Secrets Manager, cada segredo que você cria tem um ARN. Para aplicar o menor privilégio, a função de execução só deve ter acesso aos recursos necessários para a execução da função Lambda.
Você pode modificar a função de execução de uma função Lambda pesquisando-a no console do IAM ou escolhendo **Configuração** no console Lambda. Para saber mais sobre como gerenciar sua função de execução de funções Lambda, consulte. [Função de execução do Lambda](#smart-on-fhir-lambda-service-role-execution-role)
**Example Função de execução da função Lambda que concede acesso a `GetSecretValue`**
Adicionar a ação do IAM `GetSecretValue` à função de execução concede a permissão necessária para que a função de amostra do Lambda funcione.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secret-name-DKodTA"
}
]
}
```
Neste ponto, você criou uma função Lambda que pode ser usada para validar o token de acesso fornecido como parte da solicitação FHIR REST enviada ao seu SMART no armazenamento de dados habilitado para FHIR.
## Criação de uma função HealthLake de serviço para uso na função AWS Lambda usada para decodificar um JWT
**Persona: administrador do IAM**
Um usuário que pode adicionar ou remover políticas do IAM e criar novas identidades do IAM.
**Perfil de serviço**
O perfil de serviço é um [perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que um serviço assume para executar ações em seu nome. Um administrador do IAM pode criar, modificar e excluir um perfil de serviço do IAM. Para saber mais, consulte [Criar um perfil para delegar permissões a um AWS service (Serviço da AWS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) no *Guia do Usuário do IAM*.
Depois que o JSON Web Token (JWT) é decodificado, a autorização Lambda também precisa retornar um ARN de função do IAM. Essa função deve ter as permissões necessárias para realizar a solicitação da API REST ou falhará devido a permissões insuficientes.
Ao configurar uma política personalizada usando o IAM, é melhor conceder as permissões mínimas necessárias. *Para saber mais, consulte [Aplicar permissões de privilégios mínimos](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) no Guia do usuário do IAM.*
A criação HealthLake de uma função de serviço para designar na função Lambda de autorização requer duas etapas.
+ Primeiro, você precisa criar uma política do IAM. A política deve especificar o acesso aos recursos do FHIR para os quais você forneceu escopos no servidor de autorização.
+ Em segundo lugar, você precisa criar a função de serviço. Ao criar a função, você designa uma relação de confiança e anexa a política criada na etapa um. A relação de confiança é designada HealthLake como principal do serviço. Você precisa especificar um ARN do armazenamento de HealthLake dados e uma ID de AWS conta nesta etapa.
### Criação de uma nova política do IAM
Os escopos que você define em seu servidor de autorização determinam a quais recursos FHIR um usuário autenticado tem acesso em um armazenamento de dados. HealthLake
A política do IAM que você cria pode ser personalizada para corresponder aos escopos que você definiu.
As ações a seguir no `Action` elemento de uma declaração de política do IAM podem ser definidas. Para cada um `Action` na tabela, você pode definir um`Resource types`. Em HealthLake um armazenamento de dados, é o único tipo de recurso compatível que pode ser definido no `Resource` elemento de uma declaração de política de permissão do IAM.
Recursos individuais do FHIR não são um recurso que você possa definir como um elemento em uma política de permissão do IAM.
**Ações definidas por HealthLake**
| Ações | Descrição | Nível de acesso | Tipo de recurso (obrigatório) |
| --- | --- | --- | --- |
| CreateResource | Concede permissão a um recurso de criação | Gravar | ARN do armazenamento de dados: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| DeleteResource | Concede permissão para excluir um recurso | Gravar | ARN do armazenamento de dados: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| ReadResource | Concede permissão para ler um recurso | Ler | ARN do armazenamento de dados: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| SearchWithGet | Concede permissão para pesquisar recursos com o método GET | Ler | ARN do armazenamento de dados: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| SearchWithPost | Concede permissão para pesquisar recursos com o método POST | Ler | ARN do armazenamento de dados: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| Iniciar FHIRExport JobWithPost | Concede permissão para iniciar um trabalho de exportação FHIR com GET | Gravar | ARN do armazenamento de dados: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
| UpdateResource | Concede permissão para atualizar um recurso | Gravar | ARN do armazenamento de dados: arn:aws:healthlake: ::datastore/fhir/ your-region 111122223333 your-datastore-id |
Para começar, você pode usar`AmazonHealthLakeFullAccess`. Essa política permitiria leitura, gravação, pesquisa e exportação em todos os recursos do FHIR encontrados em um armazenamento de dados. Para conceder permissões somente de leitura em um armazenamento de dados, use. `AmazonHealthLakeReadOnlyAccess`
Para saber mais sobre como criar uma política personalizada usando o Console de gerenciamento da AWS, AWS CLI, ou IAM SDKs, consulte [Como criar políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do usuário do IAM*.
### Criação de uma função de serviço para HealthLake (console do IAM)
Use esse procedimento para criar uma função de serviço. Ao criar um serviço, você também precisará designar uma política do IAM.
**Para criar a função de serviço para HealthLake (console do IAM)**
1. Faça login no Console de gerenciamento da AWS e abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação do console do IAM, escolha **Perfis**.
1. Depois, escolha **Create role** (Criar perfil).
1. Na página **Selecionar entidade confiável**, escolha **Política de confiança personalizada**.
1. Em seguida, em **Política de confiança personalizada**, atualize a política de amostra da seguinte forma. **your-account-id**Substitua pelo número da sua conta e adicione o ARN do armazenamento de dados que você deseja usar em seus trabalhos de importação ou exportação.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {
"Service": "healthlake.amazonaws.com"
},
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnEquals": {
"aws:SourceArn": "arn:aws:healthlake:us-east-1:123456789012:datastore/fhir/your-datastore-id"
}
}
}
]
}
```
------
1. Em seguida, escolha **Próximo**.
1. Na página **Adicionar permissões**, escolha a política que você deseja que o HealthLake serviço assuma. Para encontrar sua política, procure-a em **Políticas de permissões**.
1. Em seguida, escolha **Anexar política**.
1. Em seguida, na página **Nome, revise e crie**, em **Nome da função**, insira um nome.
1. (Opcional) Em seguida, em **Descrição**, adicione uma breve descrição para sua função.
1. Se possível, insira um nome de função ou sufixo de nome de função para ajudar a identificar o propósito desta função. Os nomes de função devem ser exclusivos em sua Conta da AWS. Eles não são diferenciados por maiúsculas e minúsculas. Por exemplo, não é possível criar perfis denominados **PRODROLE** e **prodrole**. Como várias entidades podem fazer referência à função, não é possível editar o nome da função depois que ela é criada.
1. Revise os detalhes da função e escolha **Criar função**.
Para saber como especificar o ARN da função no exemplo da função Lambda, consulte. [Criação de uma função AWS Lambda](#smart-on-fhir-lambda-create)
## Função de execução do Lambda
A função de execução de uma função Lambda é uma função do IAM que concede à função permissão para acessar AWS serviços e recursos. Esta página fornece informações sobre como criar, visualizar e gerenciar o perfil de execução de uma função do Lambda.
Por padrão, o Lambda cria uma função de execução com permissões mínimas quando você cria uma nova função do Lambda usando o. Console de gerenciamento da AWS Para gerenciar as permissões concedidas na função de execução, consulte [Criação de uma função de execução no console do IAM](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html#permissions-executionrole-console) no *Lambda Developer* Guide.
O exemplo da função Lambda fornecido neste tópico usa o Secrets Manager para ocultar as credenciais do servidor de autorização.
Como acontece com qualquer função do IAM que você criar, é importante seguir as melhores práticas de privilégios mínimos. Durante a frase de desenvolvimento, às vezes você pode conceder permissões além do necessário. Antes de publicar sua função no ambiente de produção, como prática recomendada, ajuste a política para incluir somente as permissões necessárias. *Para obter mais informações, consulte [Aplicar o menor privilégio](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) no Guia do usuário do IAM.*
## Permitir HealthLake acionar sua função Lambda
Para que HealthLake possa invocar a função Lambda em seu nome, você deve fazer o seguinte:
+ Você precisa definir `IdpLambdaArn` igual ao ARN da função Lambda que você deseja HealthLake invocar na solicitação. `CreateFHIRDatastore`
+ Você precisa de uma política baseada em recursos que permita HealthLake invocar a função Lambda em seu nome.
Quando HealthLake recebe uma solicitação da API REST FHIR em um armazenamento de dados SMART no FHIR ativado, ele precisa de permissões para invocar a função Lambda especificada na criação do armazenamento de dados em seu nome. Para conceder HealthLake acesso, você usará uma política baseada em recursos. *Para saber mais sobre como criar uma política baseada em recursos para uma função do Lambda, consulte [Permitir que um AWS serviço chame uma função do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke) no Guia do desenvolvedor.AWS Lambda *
## Provisionando a simultaneidade para sua função Lambda
**Importante**
HealthLake exige que o tempo máximo de execução da função Lambda seja inferior a um segundo (1000 milissegundos).
Se sua função Lambda exceder o limite de tempo de execução, você receberá uma TimeOutexceção.
Para evitar essa exceção, recomendamos configurar a simultaneidade provisionada. Ao alocar simultaneidade provisionada antes de um aumento nas invocações, é possível garantir que todas as solicitações sejam atendidas por instâncias inicializadas com latência baixa. *Para saber mais sobre como configurar a simultaneidade provisionada, consulte Como configurar a simultaneidade provisionada no [Lambda Developer Guide](https://docs.aws.amazon.com/ambda/latest/dg/provisioned-concurrency.html)*
Para ver o tempo médio de execução de sua função Lambda atualmente, use a página de **monitoramento** de sua função Lambda no console Lambda. Por padrão, o console Lambda fornece um gráfico de **duração** que mostra a quantidade média, mínima e máxima de tempo que seu código de função gasta processando um evento. *Para saber mais sobre o monitoramento das funções do Lambda, consulte Funções de [monitoramento no console do Lambda no Guia do desenvolvedor do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-access-metrics.html#monitoring-console-graph-types).*
*Se você já provisionou a simultaneidade para sua função do Lambda e deseja monitorá-la, consulte Monitoramento da [simultaneidade no](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-concurrency.html) Guia do desenvolvedor do Lambda.*
# Usando autorização refinada com um SMART no armazenamento de dados habilitado para FHIR HealthLake
[Os escopos](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest) por si só não fornecem a especificidade necessária sobre quais dados um solicitante está autorizado a acessar em um armazenamento de dados. O uso de autorização refinada permite um nível mais alto de especificidade ao conceder acesso a um SMART no armazenamento de dados habilitado para FHIR. HealthLake Para usar uma autorização refinada, defina `FineGrainedAuthorizationEnabled` igual a `True` no `IdentityProviderConfiguration` parâmetro da sua solicitação. `CreateFHIRDatastore`
Se você habilitou a autorização refinada, seu servidor de autorização retornará um `fhirUser` escopo `id_token` junto com o token de acesso. Isso permite que as informações sobre o usuário sejam recuperadas pelo aplicativo do cliente. O aplicativo cliente deve tratar a `fhirUser` declaração como o URI de um recurso FHIR representando o usuário atual. Pode ser `Patient`, `Practitioner` ou `RelatedPerson`. A resposta do servidor de autorização também inclui um `user/` escopo que define quais dados o usuário pode acessar. Isso usa a sintaxe definida para escopos relacionados aos escopos específicos de recursos do FHIR:
```
user/(fhir-resource | '*').('read' | 'write' | '*')
```
A seguir estão exemplos de como a autorização refinada pode ser usada para especificar ainda mais os tipos de recursos FHIR relacionados ao acesso a dados.
+ Quando `fhirUser` é uma `Practitioner` autorização refinada determina a coleção de pacientes que o usuário pode acessar. `fhirUser`O acesso é permitido apenas para os pacientes em que o paciente se refere ao `fhirUser` como clínico geral.
```
Patient.generalPractitioner : [{Reference(Practitioner)}]
```
+ Quando `fhirUser` é um `Patient` ou `RelatedPerson` e o paciente referenciado na solicitação é diferente do`fhirUser`, uma autorização refinada determina o acesso `fhirUser` do paciente solicitado. O acesso é permitido quando há um relacionamento especificado no `Patient` recurso solicitado.
```
Patient.link.other : {Reference(Patient|RelatedPerson)}
```
# Buscando o SMART no documento FHIR Discovery
O SMART define um documento de descoberta que permite que os clientes conheçam o endpoint de autorização URLs e os recursos que um armazenamento HealthLake de dados suporta. Essas informações ajudam os clientes a direcionar as solicitações de autorização para o endpoint correto e a criar solicitações de autorização suportadas pelo armazenamento de HealthLake dados.
Para que um aplicativo cliente faça uma solicitação FHIR REST bem-sucedida HealthLake, ele deve reunir os requisitos de autorização definidos pelo armazenamento de HealthLake dados. *Não* é necessário um token de portador (autorização) para que essa solicitação seja bem-sucedida.
**Para solicitar o Documento de Descoberta para um armazenamento HealthLake de dados**
1. Colecione HealthLake `region` e `datastoreId` valorize. Para obter mais informações, consulte [Obter propriedades do datastore](managing-data-stores-describe.md).
1. Crie uma URL para a solicitação usando os valores coletados para HealthLake `region` `datastoreId` e. Anexe `/.well-known/smart-configuration` ao endpoint do URL. Para ver todo o caminho do URL no exemplo a seguir, role até o botão **Copiar**.
```
https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/.well-known/smart-configuration
```
1. Envie a solicitação usando o protocolo `GET` de [AWS assinatura Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html). Para ver o exemplo inteiro, role até o botão **Copiar**.
------
#### [ curl ]
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/.well-known/smart-configuration \
--aws-sigv4 'aws:amz:region:healthlake' \
--user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \
--header "x-amz-security-token:$AWS_SESSION_TOKEN" \
--header 'Accept: application/json'
```
------
O documento de descoberta do armazenamento de HealthLake dados retorna como um blob JSON, onde você pode encontrar o `authorization_endpoint` e o`token_endpoint`, junto com as especificações e os recursos definidos para o armazenamento de dados.
```
{
"authorization_endpoint": "https://oidc.example.com/authorize",
"token_endpoint": "https://oidc.example.com/oauth/token",
"capabilities": [
"launch-ehr",
"client-public"
]
}
```
Tanto o `authorization_endpoint` quanto o `token_endpoint` são necessários para iniciar um aplicativo cliente.
+ **Ponto final de autorização** — O URL necessário para autorizar um aplicativo ou usuário cliente.
+ **Ponto final do token** — O ponto final do servidor de autorização com o qual o aplicativo cliente usa para se comunicar.
# Fazendo uma solicitação da API FHIR REST em um armazenamento de dados habilitado para Smart HealthLake
Você pode fazer solicitações da API REST FHIR em um SMART no armazenamento de dados habilitado para HealthLake FHIR. O exemplo a seguir mostra uma solicitação do aplicativo cliente contendo um JWT no cabeçalho de autorização e como o Lambda deve decodificar a resposta. Depois que a solicitação do aplicativo cliente for autorizada e autenticada, ela deverá receber um token portador do servidor de autorização. Use o token do portador no cabeçalho de autorização ao enviar uma solicitação da API REST FHIR em um SMART no armazenamento de dados habilitado para HealthLake FHIR.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/[ID]
Authorization: Bearer auth-server-provided-bearer-token
```
Como um token portador foi encontrado no cabeçalho de autorização e nenhuma identidade AWS do IAM foi detectada, HealthLake invoca a função Lambda especificada quando o SMART no armazenamento de dados habilitado para FHIR foi criado. HealthLake Quando o token é decodificado com sucesso pela sua função Lambda, o exemplo de resposta a seguir é enviado para. HealthLake
```
{
"authPayload": {
"iss": "https://authorization-server-endpoint/oauth2/token", # The issuer identifier of the authorization server
"aud": "https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/", # Required, data store endpoint
"iat": 1677115637, # Identifies the time at which the token was issued
"nbf": 1677115637, # Required, the earliest time the JWT would be valid
"exp": 1997877061, # Required, the time at which the JWT is no longer valid
"isAuthorized": "true", # Required, boolean indicating the request has been authorized
"uid": "100101", # Unique identifier returned by the auth server
"scope": "system/*.*" # Required, the scope of the request
},
"iamRoleARN": "iam-role-arn" #Required, IAM role to complete the request
}
```
# Suporte FHIR R4 para AWS HealthLake
AWS HealthLake suporta a especificação FHIR R4 para troca de dados de saúde. As seções a seguir fornecem informações de suporte sobre como HealthLake utiliza a especificação FHIR R4 para ajudá-lo a [gerenciar](managing-fhir-resources.md) e [pesquisar](searching-fhir-resources.md) recursos FHIR em seu HealthLake armazenamento de dados usando o FHIR R4. RESTful APIs
**Topics**
+ [Declaração de capacidade](reference-fhir-capability-statement.md)
+ [Validações de perfil](reference-fhir-profile-validations.md)
+ [Resource types](reference-fhir-resource-types.md)
+ [Parâmetros de pesquisa](reference-fhir-search-parameters.md)
+ [\$1Operações](reference-fhir-operations.md)
# Declaração de capacidade do FHIR R4 para AWS HealthLake
Para encontrar os recursos (comportamentos) relacionados ao FHIR de um armazenamento de HealthLake dados ativo, você deve recuperar sua Declaração de Capacidade. A Declaração de Capacidade é usada como uma declaração da funcionalidade real do servidor ou uma declaração da implementação necessária ou desejada do servidor. A [https://hl7.org/fhir/R4/http.html#capabilities](https://hl7.org/fhir/R4/http.html#capabilities)interação FHIR recupera informações sobre HealthLake os recursos do armazenamento de dados e quais partes da especificação FHIR ela suporta. HealthLake valida os tipos de recursos FHIR de acordo com o recurso FHIR R4. [https://hl7.org/fhir/R4/structuredefinition.html](https://hl7.org/fhir/R4/structuredefinition.html)
**Para obter a Declaração de Capacidade para um armazenamento HealthLake de dados**
1. Colecione HealthLake `region` e `datastoreId` valorize. Para obter mais informações, consulte [Obter propriedades do datastore](managing-data-stores-describe.md).
1. Crie uma URL para a solicitação usando os valores coletados para HealthLake `region` `datastoreId` e. Inclua também o `metadata` elemento FHIR no URL. Para ver todo o caminho do URL no exemplo a seguir, role até o botão **Copiar**.
```
https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/metadata
```
1. Envie a solicitação . A `capabilities` interação FHIR usa uma `GET` solicitação com o protocolo de [AWS assinatura Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html). O `curl` exemplo a seguir obtém a Declaração de Capacidade para o armazenamento de HealthLake dados especificado pelo`datastoreId`. Para ver o exemplo inteiro, role até o botão **Copiar**.
------
#### [ curl ]
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/metadata \
--aws-sigv4 'aws:amz:region:healthlake' \
--user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \
--header "x-amz-security-token:$AWS_SESSION_TOKEN" \
--header 'Accept: application/json'
```
------
Você receberá um código de resposta `200` HTTP e a Declaração de Capacidade para seu armazenamento HealthLake de dados. Para obter mais informações, consulte a [https://hl7.org/fhir/R4/capabilitystatement.html](https://hl7.org/fhir/R4/capabilitystatement.html)documentação do **FHIR R4**.
# Validações de perfil FHIR para HealthLake
AWS HealthLake suporta a especificação básica [FHIR R4](https://hl7.org/fhir/R4). Incluídos na especificação básica do FHIR R4 estão os perfis FHIR. Os perfis são usados em um tipo de recurso FHIR para definir uma definição de tipo de recurso mais específica usando and/or extensões de restrições no tipo de recurso base. Por exemplo, um perfil FHIR pode identificar campos obrigatórios, como extensões e conjuntos de valores. Um recurso pode oferecer suporte a vários perfis. Todos os armazenamentos HealthLake de dados suportam o uso de perfis FHIR.
**nota**
*Não* é necessário adicionar um perfil FHIR ao adicionar dados a um armazenamento de HealthLake dados. Se um perfil FHIR não for especificado quando um recurso for adicionado ou atualizado, o recurso será validado somente com base no esquema FHIR R4.
Os perfis FHIR, aos quais os recursos do FHIR estão em conformidade, são incluídos nos recursos antes de serem importados. HealthLake Portanto, os perfis FHIR são validados HealthLake durante a importação.
Os perfis FHIR são especificados em um guia de implementação. Um Guia de Implementação (IG) do FHIR é um conjunto de instruções que descrevem como usar o padrão FHIR para uma finalidade específica. HealthLake valida os perfis FHIR definidos nos guias de implementação a seguir.
**Perfis FHIR suportados por AWS HealthLake**
| Nome | Versão | Guia de implementação | Recurso | Leste dos EUA (Ohio) | Leste dos EUA (N. da Virgínia) | Oeste dos EUA (Oregon) | Ásia-Pacífico (Mumbai) | Ásia-Pacífico (Sydney) | Canada (Central) | Europa (Irlanda) | Europa (Londres) |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Núcleo dos EUA | 3.1.1 | [http://hl7.org/fhir/us/core/STU3.1.1/](http://hl7.org/fhir/us/core/STU3.1.1/) | Padrão | X | X | X | X | X | X | X | X |
| Núcleo dos EUA | 4.0.0 | [https://hl7.org/fhir/us/core/STU4/index.html](https://hl7.org/fhir/us/core/STU4/index.html) | Compatível | X | X | X | X | X | X | X | X |
| Núcleo dos EUA | 5.0.1 | [https://hl7.org/fhir/us/core/STU5.0.1/index.html](https://hl7.org/fhir/us/core/STU5.0.1/index.html) | Compatível | X | X | X | X | X | X | X | X |
| Núcleo dos EUA | 6.1.0 | [https://hl7.org/fhir/us/core/STU6.1/index.html](https://hl7.org/fhir/us/core/STU6.1/index.html) | Compatível | X | X | X | X | X | X | X | X |
| Núcleo dos EUA | 7.0.0 | [https://hl7.org/fhir/us/core/STU7/](https://hl7.org/fhir/us/core/STU7/) | Compatível | X | X | X | X | X | X | X | X |
| Core do Reino Unido | 2.0.1 | [https://simplifier.net/guide/uk-core-implementation-guide-stu2/Home/ProfilesandExtensions/ProfilesIndex?version=2.0.1](https://simplifier.net/guide/uk-core-implementation-guide-stu2/Home/ProfilesandExtensions/ProfilesIndex?version=2.0.1) | Compatível | X | X | X | X | | | X | X |
| Botão azul CARIN | 1.1.0 | [http://hl7.org/fhir/us/carin-bb/STU1.1/](http://hl7.org/fhir/us/carin-bb/STU1.1/) | Padrão | X | X | X | X | X | X | X | X |
| Botão azul CARIN | 1.0.0, 2.0.0, 2.1.0 | [https://hl7.org/fhir/us/carin-bb/history.html](https://hl7.org/fhir/us/carin-bb/history.html) | Compatível | X | X | X | X | X | X | X | X |
| Troca de Dados do Pagador Da Vinci | 1.0.0 | [https://hl7.org/fhir/us/davinci-pdex/](https://hl7.org/fhir/us/davinci-pdex/) | Padrão | X | X | X | X | X | X | X | X |
| Troca de Dados do Pagador Da Vinci | 2.0.0, 2.1.0 | [https://hl7.org/fhir/us/davinci-pdex/history.html](https://hl7.org/fhir/us/davinci-pdex/history.html) | Compatível | X | X | X | X | X | X | X | X |
| Bolsa de Registros de Saúde Da Vinci () HRex | 0.2.0 | [https://hl7.org/fhir/us/davinci-hrex/2020Sep/](https://hl7.org/fhir/us/davinci-hrex/2020Sep/) | Padrão | X | X | X | X | X | X | X | X |
| DaVinci Plano PDEX Net | 1.1.0 | [https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1.1/](https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1.1/) | Padrão | X | X | X | X | X | X | X | X |
| DaVinci Plano PDEX Net | 1.0.0 | [https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1/](https://hl7.org/fhir/us/davinci-pdex-plan-net/STU1/) | Compatível | X | X | X | X | X | X | X | X |
| DaVinci Payer Data Exchange (PDex) Formulário de medicamentos dos EUA | 1.1.0 | [https://hl7.org/fhir/us/davinci-drug-formulary/STU1.1/](https://hl7.org/fhir/us/davinci-drug-formulary/STU1.1/) | Padrão | X | X | X | X | X | X | X | X |
| DaVinci Payer Data Exchange (PDex) Formulário de medicamentos dos EUA | 1.0.1, 2.0.1, 2.1.0 | [https://hl7.org/fhir/us/davinci-drug-formulary/history.html](https://hl7.org/fhir/us/davinci-drug-formulary/history.html) | Compatível | X | X | X | X | X | X | X | X |
| Troca de Dados Clínicos Da Vinci () CDex | 2.1.0 | [https://build.fhir.org/ig/HL7/davinci-ecdx/index.html](https://build.fhir.org/ig/HL7/davinci-ecdx/index.html) | Padrão | X | X | X | X | X | X | X | X |
| Da Vinci Previous Authorization Support (PAS) FHIR IG | 2.1.0 | [https://hl7.org/fhir/us/davinci-pas/](https://hl7.org/fhir/us/davinci-pas/) | Padrão | X | X | X | X | X | X | X | X |
| Guia de implementação do NCQA HEDIS® | 0.3.1 | [https://www.ncqa.org/resources/hedis-ig-resource-page/](https://www.ncqa.org/resources/hedis-ig-resource-page/) | Padrão | X | X | X | X | | | X | X |
| Resumo internacional do paciente (IPS) | 2.0.0 - cédula | [https://hl7.org/fhir/uv/ips/2024Sep/](https://hl7.org/fhir/uv/ips/2024Sep/) | Padrão | X | X | X | X | X | X | X | X |
| Medida de qualidade | 5.0.0 | [https://registry.fhir.org/package/hl7.fhir.us.cqfmeasures%7C5.0.0](https://registry.fhir.org/package/hl7.fhir.us.cqfmeasures%7C5.0.0) | Padrão | X | X | X | X | | | X | X |
| Relatórios genômicos | 3.0.0 | [https://build.fhir.org/ig/HL7/genomics-reporting/index.html](https://build.fhir.org/ig/HL7/genomics-reporting/index.html) | Padrão | X | X | X | X | | | X | X |
| Missão Digital Ayushman Bharat (ABDM) da Autoridade Nacional de Saúde | 2,0 | [https://www.nrces.in/ndhm/fhir/r4/index.html](https://www.nrces.in/ndhm/fhir/r4/index.html) | Padrão | X | X | X | X | | | X | X |
| CA Core \$1 | 1.1.0 | [https://simplifier.net/ca-core](https://simplifier.net/ca-core) | Compatível | | | | | | X | | |
| CA: Consulta Pan-Canadense de Referência da EREC | 1.1.0 | [https://simplifier.net/CA-eReC/~introduction](https://simplifier.net/CA-eReC/~introduction) | Compatível | | | | | | X | | |
| Resumo do paciente, edição canadense - (PS-CA) | 2.11 | [https://simplifier.net/PS-CA-R1/~introduction](https://simplifier.net/PS-CA-R1/~introduction) | Compatível | | | | | | X | | |
| Repositório Digital de Medicamentos para Saúde de Ontário | 4.0.3 | [https://simplifier.net/ca-on-dhdr-r4/~introduction](https://simplifier.net/ca-on-dhdr-r4/~introduction) | Compatível | | | | | | X | | |
| Núcleo AU | 1.0.0 | [https://hl7.org.au/fhir/core/](https://hl7.org.au/fhir/core/) | Compatível | | | | | X | | | |
| Gestão de práticas Magentus | 1.2.16 | [https://fhir-versions.dev.geniesolutions.io/1.2.16/downloads.html](https://fhir-versions.dev.geniesolutions.io/1.2.16/downloads.html) | Compatível | | | | | X | | | |
## Validando perfis FHIR especificados em um recurso
Para que um perfil FHIR seja validado, adicione-o ao `profile` elemento de recursos individuais usando a URL do perfil designada no guia de implementação.
Os perfis FHIR são validados quando você adiciona um novo recurso ao seu armazenamento de dados. Para adicionar um novo recurso, você pode usar a operação de `StartFHIRImportJob` API, fazer uma `POST` solicitação para adicionar um novo recurso ou ` PUT ` atualizar um recurso existente.
**Example — Para ver qual perfil FHIR é referenciado em um recurso**
O URL do perfil é adicionado ao `profile` elemento no par de `"meta" : "profile"` valores-chave. Esse recurso foi truncado para maior clareza.
```
{
"resourceType": "Patient",
"id": "abcd1234efgh5678hijk9012",
"meta": {
"lastUpdated": "2023-05-30T00:48:07.8443764-07:00",
"profile": [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
]
}
}
```
**Example — Como referenciar um perfil FHIR não suportado por padrão**
Para validar em relação a um perfil não padrão compatível (por exemplo, CarinBB 1.0.0) - adicione a URL do perfil com a versão (separada por '\$1') e a URL do perfil base no elemento. `meta.profile` Este recurso de exemplo foi truncado para maior clareza.
```
{
"resourceType": "ExplanationOfBenefit",
"id": "sample-EOB",
"meta": {
"lastUpdated": "2024-02-02T05:56:09.4+00:00",
"profile": [
"http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-ExplanationOfBenefit-Pharmacy|1.0.0",
"http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-ExplanationOfBenefit-Pharmacy“
]
}
}
```
# Tipos de recursos compatíveis com FHIR R4 para HealthLake
A tabela a seguir lista os tipos de recursos do FHIR R4 suportados pelo. AWS HealthLake Para obter mais informações, consulte [Índice de recursos](https://hl7.org/fhir/R4/resourcelist.html) na documentação do **FHIR R4**.
**Tipos de recursos FHIR R4 suportados pelo HealthLake**
| | | | |
| --- |--- |--- |--- |
| Conta | DetectedIssue | Fatura | Praticante |
| ActivityDefinition | Dispositivo | Biblioteca | PractitionerRole |
| AdverseEvent | DeviceDefinition | Ligação | Procedimento |
| AllergyIntolerance | DeviceMetric | Lista | Proveniência |
| Nomeação | DeviceUseStatement | Local | Questionário |
| AppointmentResponse | DeviceRequest | Medida | QuestionnaireResponse |
| AuditEvent - Veja a nota | DiagnosticReport | MeasureReport | RelatedPerson |
| Binário | DocumentManifest | Mídia | RequestGroup |
| BodyStructure | DocumentReference | Medicação | ResearchStudy |
| Pacote - Veja a nota | EffectEvidenceSynthesis | MedicationAdministration | ResearchSubject |
| CapabilityStatement | Encontro | MedicationDispense | RiskAssessment |
| CarePlan | Endpoint | MedicationKnowledge | RiskEvidenceSynthesis |
| CareTeam | EpisodeOfCare | MedicationRequest | Agendamento |
| ChargeItem | EnrollmentRequest | MedicationStatement | ServiceRequest |
| ChargeItemDefinition | EnrollmentResponse | MessageHeader | Slot |
| Reivindicar | ExplanationOfBenefit | MolecularSequence | Espécime |
| ClaimResponse | FamilyMemberHistory | NutritionOrder | StructureDefinition |
| Comunicação | Sinalizador | Observação | StructureMap |
| CommunicationRequest | Objetivo | OperationOutcome - Veja a nota | Substance |
| Composição | Group (Grupo) | Organização | SupplyDelivery |
| ConceptMap | GuidanceResponse | OrganizationAffiliation | SupplyRequest |
| Condição | HealthcareService | Parâmetros - Veja a nota | Tarefa |
| Consentimento | ImagingStudy | Paciente | ValueSet |
| Contrato | Imunização | PaymentNotice | VisionPrescription |
| Cobertura | ImmunizationEvaluation | PaymentReconciliation | VerificationResult - Veja a nota |
| CoverageEligibilityRequest | ImmunizationRecommendation | Pessoa | |
| CoverageEligibilityResponse | InsurancePlan | PlanDefinition | |
**Especificações FHIR e HealthLake**
Você não pode fazer `GET` `POST` solicitações com FHIR `OperationOutcome` e tipos de `Parameters` recursos.
**AuditEvent**— Um AuditEvent recurso pode ser criado ou lido, mas não pode ser atualizado ou excluído.
**Bundle** — Há várias maneiras de HealthLake gerenciar solicitações de Bundle. Consulte mais detalhes em [Agrupando recursos do FHIR](managing-fhir-resources-bundle.md).
**VerificationResult**— Esse tipo de recurso só é compatível com armazenamentos de dados criados após 09 de dezembro de 2023.
# Parâmetros de pesquisa FHIR R4 para HealthLake
Use a [https://hl7.org/fhir/R4/http.html#search](https://hl7.org/fhir/R4/http.html#search)interação FHIR para pesquisar um conjunto de recursos FHIR em um armazenamento de HealthLake dados com base em alguns critérios de filtro. A `search` interação pode ser realizada usando uma `POST` solicitação `GET` ou. Para pesquisas que envolvam informações de identificação pessoal (PII) ou informações de saúde protegidas (PHI), é recomendável usar `POST` solicitações, pois PII e PHI são adicionadas como parte do corpo da solicitação e criptografadas em trânsito.
**nota**
A `search` interação FHIR descrita neste capítulo é construída em conformidade com o padrão HL7 FHIR R4 para troca de dados de assistência médica. Por ser uma representação de um serviço HL7 FHIR, não é oferecido por meio AWS CLI de e. AWS SDKs Para obter mais informações, consulte a [https://hl7.org/fhir/R4/http.html#search](https://hl7.org/fhir/R4/http.html#search)documentação da API **FHIR R4 RESTful **.
Você também pode consultar HealthLake datastores com SQL usando o Amazon Athena. Para obter mais informações, consulte Integrando.
HealthLake suporta o seguinte subconjunto de parâmetros de pesquisa do FHIR R4. Para obter mais informações, consulte [Parâmetros de pesquisa FHIR R4 para HealthLake](#reference-fhir-search-parameters).
## Tipos de parâmetros de pesquisa compatíveis
A tabela a seguir mostra os tipos de parâmetros de pesquisa suportados em HealthLake.
**Tipos de parâmetros de pesquisa compatíveis**
| Parâmetro de pesquisa | Description |
| --- | --- |
| \$1id | ID do recurso (não é um URL completo) |
| \$1Última atualização | Data da última atualização. O servidor tem poder discricionário quanto à precisão do limite. |
| \$1tag | Pesquise por uma tag de recurso. |
| \$1perfil | Pesquise todos os recursos marcados com um perfil. |
| \$1segurança | Pesquise as etiquetas de segurança aplicadas a esse recurso. |
| \$1fonte | Pesquise de onde vem o recurso. |
| \$1texto | Pesquise a narrativa do recurso. |
| createdAt | Pesquise na extensão personalizada CreatedAt. |
**nota**
Os seguintes parâmetros de pesquisa são compatíveis somente com datastores criados após 09 de dezembro de 2023: \$1security, \$1source, \$1text, createdAt.
A tabela a seguir mostra exemplos de como modificar cadeias de caracteres de consulta com base nos tipos de dados especificados para um determinado tipo de recurso. Para maior clareza, os caracteres especiais na coluna de exemplos não foram codificados. Para fazer uma consulta bem-sucedida, certifique-se de que a string de consulta tenha sido codificada corretamente.
**Exemplos de parâmetros de pesquisa**
| Tipos de parâmetros de pesquisa | Detalhes | Exemplos |
| --- | --- | --- |
| Número | Pesquisa um valor numérico em um recurso especificado. Números significativos são observados. O número de dígitos significativos é específico por valor do parâmetro de pesquisa, excluindo zeros à esquerda. Prefixos de comparação são permitidos. | `[parameter]=100` `[parameter]=1e2` `[parameter]=lt100` |
| Data/ DateTime | Pesquisa uma data ou hora específica. O formato esperado é`yyyy-mm-ddThh:mm:ss[Z\|(+\|-)hh:mm]`, mas pode variar. Aceita os seguintes tipos de dados: `date` `dateTime``instant`,`Period`,, `Timing` e. Para obter mais detalhes sobre o uso desses tipos de dados em pesquisas, consulte a [data](https://www.hl7.org/fhir/search.html#date) na documentação da **API FHIR R4 RESTful **. Prefixos de comparação são permitidos. | `[parameter]=eq2013-01-14` `[parameter]=gt2013-01-14T10:00` `[parameter]=ne2013-01-14` |
| String | Pesquisa uma sequência de caracteres com distinção entre maiúsculas e minúsculas. Suporta ambos `HumanName` os `Address` tipos. Para obter mais detalhes, consulte a entrada do [tipo de HumanName dados](https://www.hl7.org/fhir/datatypes.html#HumanName) e as entradas do [tipo de `Address` dados](https://www.hl7.org/fhir/datatypes.html#Address) na documentação do **FHIR R4**. A pesquisa avançada é suportada usando `:text` modificadores. | `[base]/Patient?given=eve` `[base]/Patient?given:contains=eve` |
| Token | Pesquisa uma close-to-exact correspondência com uma sequência de caracteres, geralmente comparada a um par de valores de código médico. A distinção entre maiúsculas e minúsculas está vinculada ao sistema de código usado ao criar uma consulta. As consultas baseadas em subsunção podem ajudar a reduzir problemas relacionados à distinção entre maiúsculas e minúsculas. Para maior clareza, não `\|` foi codificado. | `[parameter]=[system]\|[code]`: Aqui `[system]` se refere a um sistema de codificação e `[code]` se refere ao valor do código encontrado nesse sistema específico. `[parameter]=[code]`: Aqui, sua entrada corresponderá a um código ou a um sistema. `[parameter]=\|[code]`: aqui, sua entrada corresponderá a um código e a propriedade do sistema não terá identificador. |
| Composto | Pesquisa vários parâmetros em um único tipo de recurso, usando os modificadores `$` e a `,` operação. Prefixos de comparação são permitidos. | `/Patient?language=FR,NL&language=EN` `Observation?component-code-value-quantity=http://loinc.org\|8480-6$lt60` `[base]/Group?characteristic-value=gender$mixed` |
| Quantidade | Pesquisa um número, sistema e código como valores. É necessário um número, mas o sistema e o código são opcionais. Com base no tipo de dados de quantidade. Para obter mais detalhes, consulte [Quantidade](https://www.hl7.org/fhir/datatypes.html#Quantity) na documentação do **FHIR R4**. Usa a seguinte sintaxe presumida `[parameter]=[prefix][number]\|[system]\|[code]` | `[base]/Observation?value-quantity=5.4\|http://unitsofmeasure.org\|mg` `[base]/Observation?value-quantity=5.4\|http://unitsofmeasure.org\|mg` `[base]/Observation?value-quantity=5.4\|http://unitsofmeasure.org\|mg` `[base]/Observation?value-quantity=le5.4\|http://unitsofmeasure.org\|mg` |
| Referência | Pesquisa referências a outros recursos. | `[base]/Observation?subject=Patient/23` `test` |
| URI | Pesquisa uma sequência de caracteres que identifica inequivocamente um recurso específico. | `[base]/ValueSet?url=http://acme.org/fhir/ValueSet/123` |
| Especial | Pesquisas baseadas em extensões médicas integradas de PNL. |
## Parâmetros de pesquisa avançada suportados por HealthLake
HealthLake suporta os seguintes parâmetros de pesquisa avançada.
| Name (Nome) | Descrição | Exemplo | Recurso |
| --- | --- | --- | --- |
| \$1include | Usado para solicitar que recursos adicionais sejam retornados em uma solicitação de pesquisa. Ele retorna recursos que são referenciados pela instância do recurso de destino. | Encounter?\$1include=Encounter:subject | |
| \$1revinclude | Usado para solicitar que recursos adicionais sejam retornados em uma solicitação de pesquisa. Ele retorna recursos que fazem referência à instância do recurso primário. | Patient?\$1id=patient-identifier&\$1revinclude=Encounter:patient | |
| \$1summary | O resumo pode ser usado para solicitar um subconjunto do recurso. | Patient?\$1summary=text | Os seguintes parâmetros de resumo são suportados:\$1summary=true,\$1summary=false,\$1summary=text,\$1summary=data. |
| \$1elements | Solicite que um conjunto específico de elementos seja retornado como parte de um recurso nos resultados da pesquisa. | Patient?\$1elements=identifier,active,link | |
| \$1total | Retorna o número de recursos que correspondem aos parâmetros de pesquisa. | Patient?\$1total=accurate | Support\$1total=accurate,\$1total=none. |
| \$1sort | Indique a ordem de classificação dos resultados da pesquisa retornados usando uma lista separada por vírgulas. O - prefixo pode ser usado para qualquer regra de classificação na lista separada por vírgulas para indicar a ordem decrescente. | Observation?\$1sort=status,-date | Support classificar por campos com tiposNumber, String, Quantity, Token, URI, Reference. A classificação por só Date é compatível com armazenamentos de dados criados após 09 de dezembro de 2023. Support até 5 regras de classificação. |
| \$1count | Controle quantos recursos são retornados por página do pacote de pesquisa. | Patient?\$1count=100 | O tamanho máximo da página é 100. |
| chaining | Elementos de pesquisa dos recursos referenciados. O . direciona a pesquisa em cadeia para o elemento dentro do recurso referenciado. | DiagnosticReport?subject:Patient.name=peter | |
| reverse chaining (\$1has) | Pesquise um recurso com base nos elementos dos recursos que se referem a ele. | Patient?\$1has:Observation:patient:code=1234-5 | |
`_include`
O uso `_include` em uma consulta de pesquisa permite que recursos adicionais do FHIR especificados também sejam retornados. Use `_include` para incluir recursos que estão vinculados diretamente.
**Example — Para usar `_include` para encontrar os pacientes ou o grupo de pacientes que foram diagnosticados com tosse**
Você pesquisaria o tipo de `Condition` recurso especificando o código de diagnóstico para tosse e, em seguida, `_include` especificaria que deseja que o `subject` diagnóstico também seja retornado. No tipo de `Condition` recurso, `subject` refere-se ao tipo de recurso do paciente ou ao tipo de recurso do grupo.
Para maior clareza, os caracteres especiais no exemplo não foram codificados. Para fazer uma consulta bem-sucedida, certifique-se de que a sequência de caracteres de consulta tenha sido codificada corretamente.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
Condition?code=49727002&_include=Condition:subject
```
`_include:iterate`Modificador
O `_include:iterate` modificador permite a inclusão recursiva de recursos referenciados em dois níveis. Por exemplo,
```
GET /ServiceRequest?identifier=025C0931195&_include=ServiceRequest:requester&_include:iterate=PractitionerRole:practitioner
```
retornará o ServiceRequest, está associado PractitionerRole (por meio da referência do solicitante) e, em seguida, incluirá recursivamente o praticante referenciado por ela. PractitionerRole Esse modificador está disponível para todos os tipos de recursos em HealthLake.
`_include=*`Modificador
O `_include=*` modificador é um curinga que inclui automaticamente todos os recursos diretamente referenciados pelos resultados da pesquisa. Por exemplo,
```
GET /ServiceRequest?specimen.accession=12345&_include=*
```
retornará a correspondência ServiceRequest junto com todos os recursos referenciados (como paciente, médico, amostra etc.) sem precisar especificar cada caminho de referência individualmente. Esse modificador está disponível para todos os tipos de recursos em HealthLake.
`_revinclude`
O uso `_revinclude` em uma consulta de pesquisa permite que recursos adicionais do FHIR especificados também sejam retornados. Use `_revinclude` para incluir recursos vinculados de trás para frente.
**Example — Usar `_revinclude` para incluir tipos de recursos relacionados de Encontro e Observação vinculados a um paciente específico**
Para fazer essa pesquisa, você primeiro definiria o indivíduo `Patient` especificando seu identificador no parâmetro de `_id` pesquisa. Em seguida, você especificaria recursos adicionais do FHIR usando a estrutura e. `Encounter:patient` `Observation:patient`
Para maior clareza, os caracteres especiais no exemplo não foram codificados. Para fazer uma consulta bem-sucedida, certifique-se de que a sequência de caracteres de consulta tenha sido codificada corretamente.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
Patient?_id=patient-identifier&_revinclude=Encounter:patient&_revinclude=Observation:patient
```
`_summary`
O uso `_summary` em uma consulta de pesquisa permite que o usuário solicite um subconjunto do recurso FHIR. Ele pode conter um dos seguintes valores:`true, text, data, false`. Quaisquer outros valores serão tratados como inválidos. Os recursos retornados serão marcados com `'SUBSETTED'` meta.tag, para indicar que os recursos estão incompletos.
+ `true`: retorne todos os elementos suportados que estão marcados como 'resumo' na definição básica do (s) recurso (s).
+ `text`: retorne somente os elementos 'text', 'id', 'meta' e somente os elementos obrigatórios de nível superior.
+ `data`: Retorne todas as partes, exceto o elemento 'texto'.
+ `false`: Retorne todas as partes do (s) recurso (s)
Em uma única solicitação de pesquisa, `_summary=text` não pode ser combinado com `_include` ou com parâmetros de `_revinclude` pesquisa.
**Example — Obtenha o elemento “texto” dos recursos do paciente em um armazenamento de dados.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_summary=text
```
`_elements`
O uso `_elements` em uma consulta de pesquisa permite que elementos de recursos específicos do FHIR sejam solicitados. Os recursos retornados serão marcados com `'SUBSETTED'` meta.tag, para indicar que os recursos estão incompletos.
O `_elements` parâmetro consiste em uma lista separada por vírgulas de nomes de elementos básicos, como elementos definidos no nível raiz do recurso. Somente os elementos listados devem ser retornados. Se os valores dos `_elements` parâmetros contiverem elementos inválidos, o servidor os ignorará e retornará elementos obrigatórios e válidos.
`_elements`não será aplicável aos recursos incluídos (recursos retornados cujo modo de pesquisa é`include`).
Em uma única solicitação de pesquisa, `_elements` não pode ser combinado com os parâmetros `_summary` de pesquisa.
**Example — Obtenha elementos “identificadores”, “ativos” e “vinculados” dos recursos do paciente em seu armazenamento de HealthLake dados.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_elements=identifier,active,link
```
`_total`
O uso `_total` em uma consulta de pesquisa retornará o número de recursos que correspondem aos parâmetros de pesquisa solicitados. HealthLake retornará o número total de recursos correspondentes (recursos retornados cujo modo de pesquisa é`match`) na resposta `Bundle.total` da pesquisa.
`_total`suporta os `accurate` valores dos `none` parâmetros. `_total=estimate`não é suportado. Quaisquer outros valores serão tratados como inválidos. `_total`não é aplicável aos recursos incluídos (recursos retornados cujo modo de pesquisa é`include`).
**Example — Obtenha o número total de recursos do paciente em um armazenamento de dados:**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_total=accurate
```
`_sort`
O uso `_sort` na consulta de pesquisa organiza os resultados em uma ordem específica. Os resultados são ordenados com base na lista separada por vírgulas das regras de classificação em ordem de prioridade. As regras de classificação devem ser parâmetros de pesquisa válidos. Quaisquer outros valores serão tratados como inválidos.
Em uma única solicitação de pesquisa, você pode usar até 5 parâmetros de pesquisa de classificação. Opcionalmente, você pode usar um `-` prefixo para indicar a ordem decrescente. O servidor classificará em ordem crescente por padrão.
Os tipos de parâmetros de pesquisa de classificação suportados são:`Number, String, Date, Quantity, Token, URI, Reference`. Se um parâmetro de pesquisa se referir a um elemento aninhado, esse parâmetro de pesquisa não terá suporte para classificação. Por exemplo, a pesquisa por “nome” do tipo de recurso Paciente se refere ao paciente. O elemento Nome com o tipo de HumanName dados é considerado aninhado. Portanto, não há suporte para classificar os recursos do paciente por 'nome'.
**Example — Obtenha os recursos do paciente em um armazenamento de dados e classifique-os por data de nascimento em ordem crescente:**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_sort=birthdate
```
`_count`
O parâmetro `_count` é definido como uma instrução para o servidor sobre quantos recursos devem ser retornados em uma única página.
O tamanho máximo da página é 100. Qualquer valor maior que 100 é inválido. `_count=0`não é suportado.
**Example — Pesquise o recurso do paciente e defina o tamanho da página de pesquisa para 25:**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_count=25
```
`Chaining and Reverse Chaining(_has)`
O encadeamento e o encadeamento reverso no FHIR fornecem uma maneira mais eficiente e compacta de obter dados interconectados, reduzindo a necessidade de várias consultas separadas e tornando a recuperação de dados mais conveniente para desenvolvedores e usuários.
Se algum nível de recursão retornar mais de 100 resultados, HealthLake retornará 4xx para proteger o armazenamento de dados de ser sobrecarregado e causar várias paginações.
**Example — Encadeamento - Obtém tudo DiagnosticReport o que se refere a um paciente em que o nome do paciente é peter.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/DiagnosticReport?subject:Patient.name=peter
```
**Example — Encadeamento reverso - Obtenha recursos do paciente, em que o recurso do paciente é referido por pelo menos uma observação em que a observação tem um código de 1234 e onde a observação se refere ao recurso do paciente no parâmetro de pesquisa do paciente.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_has:Observation:patient:code=1234
```
## Modificadores de pesquisa compatíveis
Os modificadores de pesquisa são usados com campos baseados em strings. Todos os modificadores de pesquisa em HealthLake uso usam lógica baseada em booleanos. Por exemplo, você pode `:contains` especificar que um campo de string maior inclua uma string pequena para que seja incluído nos resultados da pesquisa.
**Modificadores de pesquisa compatíveis**
| Modificador de pesquisa | Tipo |
| --- | --- |
| :ausente | Todos os parâmetros, exceto Composite |
| :exato | String |
| :contém | String |
| :não | Token |
| :texto | Token |
| :identificador | Referência |
| :abaixo | URI |
## Comparadores de pesquisa compatíveis
Você pode usar comparadores de pesquisa para controlar a natureza da correspondência em uma pesquisa. Você pode usar comparadores ao pesquisar nos campos de número, data e quantidade. A tabela a seguir lista os comparadores de pesquisa e suas definições que são suportadas pelo HealthLake.
**Comparadores de pesquisa compatíveis**
| Comparador de pesquisa | Description |
| --- | --- |
| eq | O valor do parâmetro no recurso é igual ao valor fornecido. |
| ne | O valor do parâmetro no recurso não é igual ao valor fornecido. |
| gt | O valor do parâmetro no recurso é maior que o valor fornecido. |
| lt | O valor do parâmetro no recurso é menor que o valor fornecido. |
| idade | O valor do parâmetro no recurso é maior ou igual ao valor fornecido. |
| le | O valor do parâmetro no recurso é menor ou igual ao valor fornecido. |
| mar | O valor do parâmetro no recurso começa após o valor fornecido. |
| eb | O valor do parâmetro no recurso termina antes do valor fornecido. |
## Parâmetros de pesquisa FHIR não suportados pelo HealthLake
HealthLake suporta todos os parâmetros de pesquisa do FHIR, com exceção dos listados na tabela a seguir. Para obter uma lista completa dos parâmetros de pesquisa do FHIR, consulte o registro de parâmetros de pesquisa do [FHIR](https://hl7.org/fhir/R4/searchparameter-registry.html).
**Parâmetros de pesquisa não suportados**
| | |
| --- |--- |
| Composição do pacote | Localização próxima |
| Identificador de pacote | C onsent-source-reference |
| Mensagem do pacote | Paciente contratado |
| Tipo de pacote | Conteúdo do recurso |
| Carimbo de data/hora do pacote | Consulta de recursos |
# FHIR R4 para `$operations` HealthLake
As operações FHIR\$1 (também chamadas de “operações em dólares”) são funções especiais do lado do servidor que se estendem além das operações CRUD padrão (`Create`,, `Read``Update`,`Delete`) na especificação FHIR. Essas operações são identificadas pelo prefixo “\$1” e permitem processamento complexo, transformação de dados e operações em massa que seriam difíceis ou ineficientes de realizar usando chamadas de API REST padrão. \$1 As operações podem ser invocadas no nível do sistema, no nível do tipo de recurso ou em instâncias de recursos específicas, fornecendo maneiras flexíveis de interagir com os dados do FHIR. AWS HealthLake suporta vários FHIR`$operations`. Consulte cada página individual abaixo para obter detalhes adicionais.
**Topics**
+ [Operação FHIR R4 para `$attribution-status` HealthLake](reference-fhir-operations-attribution-status.md)
+ [Excluindo tipos de recursos com `$bulk-delete`](reference-fhir-operations-bulk-delete.md)
+ [`$bulk-member-match`operação para HealthLake](reference-fhir-operations-bulk-member-match.md)
+ [Operação FHIR R4 para `$confirm-attribution-list` HealthLake](reference-fhir-operations-confirm-attribution-list.md)
+ [Operação FHIR R4 para `$davinci-data-export` HealthLake](reference-fhir-operations-davinci-data-export.md)
+ [Gerando documentos clínicos com `$document`](reference-fhir-operations-document.md)
+ [Removendo recursos permanentemente com `$erase`](reference-fhir-operations-erase.md)
+ [Obtendo dados do paciente com `Patient/$everything`](reference-fhir-operations-everything.md)
+ [Recuperando ValueSet códigos com `$expand`](reference-fhir-operations-expand.md)
+ [Exportação de HealthLake dados com o FHIR `$export`](reference-fhir-operations-export.md)
+ [Operação FHIR para `$inquire` HealthLake](reference-fhir-operations-inquire.md)
+ [Recuperando detalhes do conceito com `$lookup`](reference-fhir-operations-lookup.md)
+ [`$member-add`operação para HealthLake](reference-fhir-operations-member-add.md)
+ [`$member-match`operação para HealthLake](reference-fhir-operations-member-match.md)
+ [`$member-remove`operação para HealthLake](reference-fhir-operations-member-remove.md)
+ [Removendo recursos do compartimento do paciente com `$purge`](reference-fhir-operations-purge.md)
+ [Operação FHIR para `$questionnaire-package` HealthLake](reference-fhir-operations-questionnaire-package.md)
+ [Operação FHIR para `$submit` HealthLake](reference-fhir-operations-submit.md)
+ [Validando recursos do FHIR com `$validate`](reference-fhir-operations-validate.md)
# Operação FHIR R4 para `$attribution-status` HealthLake
Recupera o status de atribuição de um membro específico, devolvendo um pacote contendo todos os recursos de atribuição relacionados ao paciente. Essa operação faz parte da implementação da Lista IG 2.1.0 da Lista de [Atribuição de Membros (ATR) da FHIR](https://build.fhir.org/ig/HL7/davinci-atr/spec.html).
## Endpoint
```
POST [base]/Group/[id]/$attribution-status
```
## Parâmetros da solicitação
A operação aceita os seguintes parâmetros opcionais:
| Parâmetro | Tipo | Description |
| --- | --- | --- |
| memberId | Identificador | O MemberId do membro para quem o status de atribuição é solicitado |
| Referência do paciente | Referência | Referência ao recurso do paciente no sistema do produtor |
**nota**
Um `memberId` ou `patientReference` pode ser fornecido, ou ambos para fins de validação.
## Exemplo de solicitação
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "memberId",
"valueIdentifier": {
"system": "http://example.org",
"value": "MBR123456789"
}
},
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/patient-123",
"display": "John Doe"
}
}
]
}
```
## Resposta
Retorna um pacote contendo recursos de atribuição relacionados ao paciente:
| Recurso | Cardinalidade | Local |
| --- | --- | --- |
| Paciente | 1..1 | grupo.membro.entidade |
| Cobertura | 0,1 | group.member.extension: referência de cobertura |
| Organization/Practitioner/PractitionerRole | 0,1 | group.member.extension: AttributedProvider |
| Qualquer recurso | 0,1 | group.member.extension: dados associados |
### Resposta da amostra
```
{
"resourceType": "Bundle",
"id": "bundle-response",
"meta": {
"lastUpdated": "2014-08-18T01:43:33Z"
},
"type": "collection",
"entry": [
{
"fullUrl": "http://example.org/fhir/Patient/12423",
"resource": {
"resourceType": "Patient",
"id": "12423",
"meta": {
"versionId": "1",
"lastUpdated": "2014-08-18T01:43:31Z"
},
"active": true,
"name": [
{
"use": "official",
"family": "Chalmers",
"given": ["Peter", "James"]
}
],
"gender": "male",
"birthDate": "1974-12-25"
}
},
{
"fullUrl": "http://example.org/fhir/Coverage/123456",
"resource": {
"resourceType": "Coverage",
"id": "1"
// ... additional Coverage resource details
}
},
{
"fullUrl": "http://example.org/fhir/Organization/666666",
"resource": {
"resourceType": "Organization",
"id": "2"
// ... additional Organization resource details
}
}
]
}
```
## Tratamento de erros
A operação trata das seguintes condições de erro:
| Erro | Status HTTP | Description |
| --- | --- | --- |
| Solicitação de operação inválida | 400 | Parâmetros ou estrutura de solicitação não conformes |
| Recurso de grupo não encontrado | 404 | O ID de grupo especificado não existe |
| Recurso do paciente não encontrado | 404 | A referência de paciente especificada não existe |
## Autorização e segurança
Requisitos do SMART Scope
Os clientes devem ter privilégios apropriados para ler os recursos do Grupo e os recursos de atribuição relacionados
Os mecanismos de autorização padrão do FHIR se aplicam a todas as operações
# Excluindo tipos de recursos com `$bulk-delete`
AWS HealthLake dá suporte à `$bulk-delete` operação, permitindo a exclusão de todos os recursos de um tipo específico em um armazenamento de dados. Essa operação é particularmente útil quando você precisa:
+ Realize auditorias e limpezas sazonais
+ Gerencie o ciclo de vida dos dados em grande escala
+ Remover tipos de recursos específicos
+ Cumpra as políticas de retenção de dados
## Usage
A `$bulk-delete` operação pode ser invocada usando métodos POST:
```
POST [base]/[ResourceType]/$bulk-delete?isHardDelete=false&deleteAuditEvent=true
```
## Parâmetros
| Parâmetro | Tipo | Obrigatório | Padrão | Description |
| --- | --- | --- | --- | --- |
| isHardDelete | booliano | Não | false | Quando verdadeiro, remove permanentemente os recursos do armazenamento |
| deleteAuditEvent | booleano | Não | true | Quando verdadeiro, exclui os eventos de auditoria associados |
| \$1since | string | Não | Hora de criação do armazenamento de dados | Quando inserido, seleciona a hora limite inicial para encontrar recursos com base na hora da Última Modificação. Não pode ser usado com início ou fim |
| start | string | Não | Hora de criação do armazenamento de dados | Quando inserido, seleciona o horário limite para encontrar recursos com base no horário da Última Modificação. Pode ser usado com extremidade |
| end | string | Não | Horário de envio do trabalho | Quando inserido, seleciona a hora limite final para encontrar recursos com base na hora da Última Modificação |
## Exemplos
**Exemplo de solicitação**
```
POST [base]/Observation/$bulk-delete?isHardDelete=false
```
**Exemplo de resposta**
```
{
"jobId": "jobId",
"jobStatus": "SUBMITTED"
}
```
## Status do trabalho
Para verificar o status de uma tarefa de exclusão em massa:
```
GET [base]/$bulk-delete/[jobId]
```
A operação retorna informações sobre o status do trabalho:
```
{
"datastoreId": "datastoreId",
"jobId": "jobId",
"status": "COMPLETED",
"submittedTime": "2025-10-09T15:09:51.336Z"
}
```
## Comportamento
A `$bulk-delete` operação:
1. Processa de forma assíncrona para lidar com grandes volumes de recursos
1. Mantém as transações ACID para a integridade dos dados
1. Fornece rastreamento do status do trabalho com contagens de exclusões de recursos
1. Suporta os modos de exclusão temporária e definitiva
1. Inclui registro abrangente de auditoria das atividades de exclusão
1. Permite a exclusão seletiva de versões históricas e eventos de auditoria
## Registro de auditoria
A `$bulk-delete` operação é registrada como Iniciar FHIRBulk DeleteJob e Descrever FHIRBulk DeleteJob com informações detalhadas da operação.
## Limitações
+ Quando `isHardDelete` definido como verdadeiro, os recursos excluídos permanentemente não aparecerão nos resultados da pesquisa ou `_history` nas consultas.
+ Os recursos que estão sendo excluídos por meio dessa operação podem ficar temporariamente inacessíveis durante o processamento.
+ A medição de armazenamento é ajustada somente nas versões históricas - deleteVersionHistory =false não ajusta o armazenamento do armazenamento de dados
# `$bulk-member-match`operação para HealthLake
AWS HealthLake suporta a `$bulk-member-match` operação de processamento de solicitações de correspondência de vários membros de forma assíncrona. Essa operação permite que as organizações de saúde combinem com eficiência centenas de identificadores exclusivos de membros em diferentes sistemas de saúde usando informações demográficas e de cobertura em uma única solicitação em massa. [Esse recurso é essencial para troca de payer-to-payer dados em grande escala, transições de membros e requisitos de conformidade do CMS e segue a especificação FHIR.](https://build.fhir.org/ig/HL7/davinci-epdx/OperationDefinition-BulkMemberMatch.html)
**nota**
A `$bulk-member-match` operação é baseada em uma especificação FHIR subjacente que atualmente é experimental e está sujeita a alterações. Conforme a especificação evolui, o comportamento e a interface dessa API serão atualizados adequadamente. Recomenda-se que os desenvolvedores monitorem as notas de HealthLake lançamento da AWS e as atualizações relevantes da especificação FHIR para se manterem informados sobre quaisquer alterações que possam afetar suas integrações.
Essa operação é particularmente útil quando você precisa:
+ Processe a correspondência de membros em grande escala durante os períodos de inscrição aberta
+ Facilite as transições de membros em massa entre pagadores
+ Support os requisitos de troca de dados de conformidade do CMS em grande escala
+ Combine eficientemente grupos de membros em todas as redes de saúde
+ Minimize as chamadas de API e melhore a eficiência operacional para cenários de correspondência de alto volume
## Usage
A `$bulk-member-match` operação é uma operação assíncrona invocada em recursos do Grupo usando o método POST:
```
POST [base]/Group/$bulk-member-match
```
Depois de enviar uma solicitação de correspondência em massa, você pode pesquisar o status do trabalho usando:
```
GET [base]/$bulk-member-match-status/{jobId}
```
## Parâmetros compatíveis
HealthLake suporta os seguintes parâmetros FHIR: `$bulk-member-match`
| Parâmetro | Tipo | Obrigatório | Description |
| --- | --- | --- | --- |
| `MemberPatient` | Paciente | Sim | Recurso para pacientes contendo informações demográficas para o membro a ser combinado. |
| `CoverageToMatch` | Cobertura | Sim | Recurso de cobertura que será usado para comparar com os registros existentes. |
| `CoverageToLink` | Cobertura | Não | Recurso de cobertura a ser vinculado durante o processo de correspondência. |
| `Consent` | Consentimento | Sim | O recurso de consentimento para fins de autorização também é armazenado. Isso é diferente da `$member-match` operação individual em que o consentimento *não* é necessário. |
## Solicitação POST para enviar uma vaga de correspondência de membros em massa
O exemplo a seguir mostra uma solicitação POST para enviar um trabalho por correspondência de membros em massa. Cada membro é encapsulado em um `MemberBundle` parâmetro contendo os `Consent` recursos e os recursos necessários `MemberPatient``CoverageToMatch`, além de um opcional`CoverageToLink`.
```
POST [base]/Group/$bulk-member-match
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "MemberBundle",
"part": [
{
"name": "MemberPatient",
"resource": {
"resourceType": "Patient",
"identifier": [
{
"system": "http://example.org/patient-id",
"value": "patient-0"
}
],
"name": [
{
"family": "Smith",
"given": ["James"]
}
],
"gender": "male",
"birthDate": "1950-01-01"
}
},
{
"name": "CoverageToMatch",
"resource": {
"resourceType": "Coverage",
"status": "active",
"identifier": [
{
"system": "http://example.org/coverage-id",
"value": "cov-0"
}
],
"subscriberId": "sub-0",
"beneficiary": {
"reference": "Patient/patient123"
},
"relationship": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code": "self"
}
]
},
"payor": [
{
"reference": "Organization/org123"
}
]
}
},
{
"name": "Consent",
"resource": {
"resourceType": "Consent",
"status": "active",
"scope": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/consentscope",
"code": "patient-privacy"
}
]
},
"category": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
"code": "IDSCL"
}
]
}
],
"patient": {
"reference": "Patient/patient123"
},
"performer": [
{
"reference": "Patient/patient123"
}
],
"sourceReference": {
"reference": "http://example.org/DocumentReference/consent-source"
},
"policy": [
{
"uri": "http://hl7.org/fhir/us/davinci-hrex/StructureDefinition-hrex-consent.html#regular"
}
],
"provision": {
"type": "permit",
"period": {
"start": "2024-01-01",
"end": "2025-12-31"
},
"actor": [
{
"role": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
"code": "performer"
}
]
},
"reference": {
"identifier": {
"system": "http://hl7.org/fhir/sid/us-npi",
"value": "9876543210"
},
"display": "Old Health Plan"
}
},
{
"role": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
"code": "IRCP"
}
]
},
"reference": {
"identifier": {
"system": "http://hl7.org/fhir/sid/us-npi",
"value": "0123456789"
},
"display": "New Health Plan"
}
}
],
"action": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/consentaction",
"code": "disclose"
}
]
}
]
}
}
},
{
"name": "CoverageToLink",
"resource": {
"resourceType": "Coverage",
"status": "active",
"identifier": [
{
"system": "http://example.org/coverage-link-id",
"value": "cov-link-0"
}
],
"subscriberId": "new-sub-0",
"beneficiary": {
"reference": "Patient/patient123"
},
"relationship": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code": "self"
}
]
},
"payor": [
{
"identifier": {
"system": "http://hl7.org/fhir/sid/us-npi",
"value": "0123456789"
},
"display": "New Health Plan"
}
]
}
}
]
}
]
}
```
## Resposta de trabalho concluída com saída
Quando o trabalho é concluído, a resposta inclui metadados do trabalho e um recurso de parâmetros FHIR contendo três recursos de grupo que categorizam os resultados da correspondência.
```
{
"datastoreId": "datastoreId",
"jobId": "jobId",
"status": "COMPLETED",
"submittedTime": "2026-03-20T18:45:26.321Z",
"numberOfMembers": 3,
"numberOfMembersProcessedSuccessfully": 3,
"numberOfMembersWithCustomerError": 0,
"numberOfMembersWithServerError": 0,
"output": {
"resourceType": "Parameters",
"meta": {
"profile": [
"http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/pdex-parameters-multi-member-match-bundle-out"
]
},
"parameter": [
{
"name": "MatchedMembers",
"resource": {
"resourceType": "Group",
"id": "group1",
"text": {
"status": "generated",
"div": "Matched members group
"
},
"contained": [
{
"resourceType": "Patient",
"id": "1",
"identifier": [
{
"system": "http://example.org/patient-id",
"value": "patient-0"
}
],
"name": [
{
"family": "Smith",
"given": ["James"]
}
],
"gender": "male",
"birthDate": "1950-01-01"
}
],
"type": "person",
"actual": true,
"code": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-pdex/CodeSystem/PdexMultiMemberMatchResultCS",
"code": "match",
"display": "Matched"
}
]
},
"quantity": 1,
"member": [
{
"entity": {
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/base-ext-match-parameters",
"valueReference": {
"reference": "#1"
}
}
],
"reference": "Patient/patient123"
}
}
]
}
},
{
"name": "NonMatchedMembers",
"resource": {
"resourceType": "Group",
"id": "Group2",
"text": {
"status": "generated",
"div": "Non-matched members group
"
},
"contained": [
{
"resourceType": "Patient",
"id": "1",
"identifier": [
{
"system": "http://example.org/patient-id",
"value": "patient-501"
}
],
"name": [
{
"family": "Carter",
"given": ["Emily"]
}
],
"gender": "female",
"birthDate": "1985-06-15"
}
],
"type": "person",
"actual": true,
"code": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-pdex/CodeSystem/PdexMultiMemberMatchResultCS",
"code": "nomatch",
"display": "Not Matched"
}
]
},
"quantity": 1,
"member": [
{
"entity": {
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/base-ext-match-parameters",
"valueReference": {
"reference": "#1"
}
}
],
"reference": "Patient/patient123"
}
}
]
}
},
{
"name": "ConsentConstrainedMembers",
"resource": {
"resourceType": "Group",
"id": "group3",
"text": {
"status": "generated",
"div": "Consent constrained members group
"
},
"contained": [
{
"resourceType": "Patient",
"id": "1",
"identifier": [
{
"system": "http://example.org/patient-id",
"value": "patient-502"
}
],
"name": [
{
"family": "Nguyen",
"given": ["David"]
}
],
"gender": "male",
"birthDate": "1972-11-22"
}
],
"type": "person",
"actual": true,
"code": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-pdex/CodeSystem/PdexMultiMemberMatchResultCS",
"code": "consentconstraint",
"display": "Consent Constraint"
}
]
},
"quantity": 1,
"member": [
{
"entity": {
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-pdex/StructureDefinition/base-ext-match-parameters",
"valueReference": {
"reference": "#1"
}
}
],
"reference": "Patient/123"
}
}
]
}
}
]
}
}
```
## Recursos do Grupo de Saída
O trabalho concluído retorna um recurso de Parâmetros contendo três recursos do Grupo:
**MatchedMembers Group (Grupo)**
Contém referências de pacientes para todos os membros combinados com sucesso e não é categorizado como restrição de consentimento.
O `Group.quantity` campo contém a contagem total de membros em cada um de seus respectivos grupos.
**NonMatchedMembers Group (Grupo)**
Contém referências a membros em que nenhuma correspondência foi encontrada ou várias correspondências foram identificadas.
**ConsentConstrainedMembers Group (Grupo)**
Contém referências de pacientes para todos os membros combinados com sucesso, onde restrições de consentimento impedem o compartilhamento de dados. Um recurso de consentimento é considerado restrito quando as duas condições a seguir estão presentes:
+ **O URI da política termina em `#sensitive`** — Esse é o sinal mais claro e direto. O pagador responsável pelo envio está explicitamente dizendo: “Os dados deste membro são confidenciais — manuseie-os com cuidado”.
```
"policy": [{ "uri": "...hrex-consent.html#sensitive" }]
```
+ **O tipo de provisão de nível superior é `deny`** — O membro recusou amplamente o compartilhamento de dados.
```
"provision": { "type": "deny" }
```
## Integração com \$1 davinci-data-export
O recurso de MatchedMembers grupo retornado por `$bulk-member-match` pode ser usado diretamente com a `$davinci-data-export` operação para recuperar dados de membros em massa:
```
POST [base]/Group/{matched-group-id}/$davinci-data-export
GET [base]/Group/{matched-group-id}
```
Essa integração permite fluxos de trabalho eficientes em que você primeiro identifica os membros correspondentes em massa e depois exporta seus registros de saúde completos usando o recurso de grupo resultante.
## Características de desempenho
A `$bulk-member-match` operação foi projetada para processamento de alto volume e é executada de forma assíncrona:
+ **Concorrência**: máximo de 5 operações simultâneas por armazenamento de dados.
+ **Escalabilidade**: lida com até 500 membros por solicitação (limite de carga útil de 5 MB).
+ **Operações paralelas**: Compatível com operações simultâneas de importação, exportação ou exclusão em massa.
## Autorização
A API usa SMART no protocolo de autorização FHIR com os seguintes escopos obrigatórios:
+ `system/Patient.read`— Necessário para pesquisar e combinar os recursos do paciente.
+ `system/Coverage.read`— Necessário para validar as informações de cobertura.
+ `system/Group.write`— Necessário para criar recursos do Grupo de resultados.
+ `system/Organization.read`— Condicional, obrigatório se a cobertura fizer referência a organizações.
+ `system/Practitioner.read`— Condicional, exigido se a cobertura fizer referência a profissionais.
+ `system/PractitionerRole.read`— Condicional, exigido se a cobertura fizer referência às funções dos profissionais.
+ `system/Consent.write`— Condicional, exigido se os recursos de consentimento forem fornecidos.
A operação também oferece suporte à autorização AWS do IAM Signature Version 4 (SigV4) para acesso programático.
## Tratamento de erros
A operação trata das seguintes condições de erro:
+ **400 Solicitação inválida**: formato de solicitação inválido, parâmetros obrigatórios ausentes ou a carga excede os limites de tamanho (500 membros ou 5 MB).
+ **422 Entidade não processável**: erros de processamento durante a execução do trabalho.
+ **Erros individuais de membros**: quando um membro específico não consegue processar, a operação continua com os membros restantes e inclui detalhes do erro no NonMatchedMembers Grupo com códigos de motivo apropriados. Por exemplo, um `MemberBundle` paciente sem o `birthDate` parâmetro retornará o seguinte erro:
```
"errors": [
{
"memberIndex": 1,
"jsonBlob": {
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "invalid",
"diagnostics": "MemberPatient.birthDate is required"
}
],
"statusCode": 400
}
}
]
```
Os detalhes do erro estão disponíveis por meio do endpoint da pesquisa de status e incluem:
+ `numberOfMembersWithCustomerError`: Contagem de membros com erros de validação ou entrada.
+ `numberOfMembersWithServerError`: contagem de membros com erros de processamento no servidor.
## Operações do relacionadas
+ [`$member-match`operação para HealthLake](reference-fhir-operations-member-match.md)— Operação de correspondência de membros individuais.
+ [Operação FHIR R4 para `$davinci-data-export` HealthLake](reference-fhir-operations-davinci-data-export.md)— Exportação de dados em massa usando recursos do Grupo.
+ [FHIR R4 para `$operations` HealthLake](reference-fhir-operations.md)— Lista completa das operações suportadas.
# Operação FHIR R4 para `$confirm-attribution-list` HealthLake
Indica ao produtor que o consumidor não tem mais alterações a fazer na Lista de atribuição. Essa operação finaliza a lista de atribuição removendo membros inativos da lista, alterando o status para “final” e confirmando a operação. Essa operação faz parte da implementação da [FHIR Member Attribution (ATR)](https://build.fhir.org/ig/HL7/davinci-atr/spec.html) List IG 2.1.0.
## Endpoint
```
POST [base]/Group/[id]/$confirm-attribution-list
```
## Solicitação
Não são necessários parâmetros.
```
POST [base]/Group/[id]/$confirm-attribution-list
```
## Resposta
Retorna HTTP 201 com uma mensagem de confirmação.
### Resposta da amostra
```
HTTP Status Code: 201
{
"resourceType": "Parameters",
"parameter": [
{
"name": "message",
"valueString": "Accepted."
}
]
}
```
## Status do grupo após a confirmação
Após a confirmação bem-sucedida, o recurso do Grupo terá o status da lista de atribuições definido como “final”:
```
{
"resourceType": "Group",
"id": "fullexample",
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-atr/StructureDefinition/ext-attributionListStatus",
"valueCode": "final"
}
]
// ... other Group properties
}
```
## Tratamento de erros
A operação trata das seguintes condições de erro:
| Erro | Status HTTP | Description |
| --- | --- | --- |
| Solicitação de operação inválida | 400 | Parâmetros ou estrutura de solicitação não conformes |
| Recurso de grupo não encontrado | 404 | O ID de grupo especificado não existe |
## Autorização e segurança
Requisitos do SMART Scope
Os clientes devem ter privilégios apropriados para ler os recursos do Grupo e os recursos de atribuição relacionados
Pois`$confirm-attribution-list`, os clientes também devem ter privilégios de gravação para modificar os recursos do Grupo
Os mecanismos de autorização padrão do FHIR se aplicam a todas as operações
# Operação FHIR R4 para `$davinci-data-export` HealthLake
A `$davinci-data-export` operação é uma operação FHIR assíncrona que você pode usar para exportar dados de saúde. AWS HealthLake Essa operação oferece suporte a vários tipos de exportação, incluindo Atribuição de Membro (ATR) Payer-to-Payer, Acesso ao PDex Provedor e Acesso ao Membro. APIs É uma versão especializada da `$export` operação padrão do FHIR, projetada para atender aos requisitos dos guias de DaVinci implementação.
## Recursos principais
+ *Processamento assíncrono*: segue o padrão de solicitação assíncrona FHIR
+ *Exportação em nível de grupo*: exporta dados para membros em um recurso de grupo específico
+ *Vários tipos de exportação*: suporta ATR (atribuição de membros), acesso de PDex provedor e acesso de membros Payer-to-Payer APIs
+ *Suporte abrangente de perfis*: inclui US Core, CARIN Blue Button e PDex perfis
+ *Filtragem flexível*: suporta a filtragem por pacientes, tipos de recursos e intervalos de tempo
+ *Saída NDJSON*: fornece dados no formato JSON delimitado por nova linha
## Ponto final da operação
```
GET [base]/Group/[id]/$davinci-data-export
POST [base]/Group/[id]/$davinci-data-export
```
## Parâmetros da solicitação
| Parâmetro | Cardinalidade | Description |
| --- | --- | --- |
| patient | 0.. \$1 | Membros específicos cujos dados devem ser exportados. Quando omitidos, todos os membros do Grupo são exportados. |
| \$1type | 0,1 | Lista delimitada por vírgula dos tipos de recursos FHIR a serem exportados. |
| \$1since | 0,1 | Inclua somente recursos atualizados após essa data e hora. |
| \$1until | 0,1 | Inclua somente recursos atualizados antes dessa data e hora. |
| exportType | 0,1 | Tipo de exportação a ser executada. Valores válidos: hl7.fhir.us.davinci-atr, hl7.fhir.us.davinci-pdex, hl7.fhir.us.davinci-pdex.p2p, hl7.fhir.us.davinci-pdex.member. Padrão: hl7.fhir.us.davinci-atr. |
| \$1includeEOB2xWoFinancial | 0,1 | Especifica se os recursos do CARIN BB 2.x devem ser incluídos com ExplanationOfBenefit os dados financeiros removidos. Padrão: false. |
### Tipos de recursos compatíveis
Os tipos de recursos suportados dependem do tipo de exportação que você especificar. Para exportações de ATR, os seguintes tipos de recursos são suportados:
+ `Group`
+ `Patient`
+ `Coverage`
+ `RelatedPerson`
+ `Practitioner`
+ `PractitionerRole`
+ `Organization`
+ `Location`
Para PDex exportações (Provider Access e Member Access), todos os tipos de recursos clínicos e de sinistros são suportados, além dos tipos anteriores. Payer-to-Payer Para obter uma lista completa dos tipos de recursos suportados, consulte o [US Core Implementation Guide (STU 6.1)](https://hl7.org/fhir/us/core/STU6.1/), o [CARIN Blue Button Implementation Guide](https://hl7.org/fhir/us/carin-bb/) e o [Da Vinci Prior Authorization Support Implementation](https://hl7.org/fhir/us/davinci-pas/) Guide.
## Tipos de exportação
A `$davinci-data-export` operação suporta os seguintes tipos de exportação. Você especifica o tipo de exportação usando o `exportType` parâmetro.
| Tipo de exportação | Finalidade | Escopo de dados | Limite temporal |
| --- | --- | --- | --- |
| hl7.fhir.us.davinci-atr | Lista de atribuição de membros | Recursos relacionados à atribuição | Nenhum |
| hl7.fhir.us.davinci-pdex | API de acesso do provedor | Dados clínicos e de reclamações de pacientes atribuídos | 5 anos |
| hl7.fhir.us.davinci-pdex.p2p | Payer-to-Payer Troca | Dados históricos de associados para transições de seguros | 5 anos |
| hl7.fhir.us.davinci-pdex.member | API de acesso de membros | Dados de saúde do próprio membro | 5 anos |
**nota**
Para PDex exportações, o limite temporal de 5 anos não se aplica aos tipos de recursos ATR (`Group`,,`Patient`,`Coverage`,`RelatedPerson`,, `Practitioner` `PractitionerRole``Organization`,`Location`). Esses recursos estão sempre incluídos, independentemente da idade.
### ATR (hl7.fhir.us.davinci-atr)
Com o tipo de exportação ATR, você pode exportar dados da Lista de Atribuição de Membros. Use esse tipo de exportação para recuperar recursos relacionados à atribuição para membros de um grupo. Para obter mais informações, consulte a Operação de [exportação de ATR Da Vinci](https://build.fhir.org/ig/HL7/davinci-atr/OperationDefinition-davinci-data-export.html).
Tipos de recursos compatíveis
`Group`, `Patient`, `Coverage`, `RelatedPerson`, `Practitioner`, `PractitionerRole`, `Organization`, `Location`
Filtragem temporal
Nenhuma filtragem temporal é aplicada. Todos os recursos correspondentes são exportados independentemente da data.
### PDex Tipos de exportação
Todos os tipos de PDex exportação compartilham os mesmos perfis suportados e a mesma lógica de filtragem. Para obter mais informações, consulte a [API Da Vinci PDex Provider Access](https://build.fhir.org/ig/HL7/davinci-epdx/provider-access-api.html). Os seguintes perfis são compatíveis:
+ US Core 3.1.1, 6.1.0 e 7.0.0
+ PDex Autorização prévia (não suportada para acesso de membros)
+ Perfis básicos do CARIN BB 2.x: Institucional de Internação, Institucional Ambulatorial, Profissional, Oral, Farmácia NonClinician
Acesso do provedor (`hl7.fhir.us.davinci-pdex`)
Permite que os provedores da rede recuperem dados de pacientes atribuídos.
Payer-to-Payer (`hl7.fhir.us.davinci-pdex.p2p`)
Permite a troca de dados entre pagadores quando um paciente muda de seguro.
Acesso de membro (`hl7.fhir.us.davinci-pdex.member`)
Permite que os membros acessem seus próprios dados de saúde. Esse tipo de exportação pode incluir dados financeiros nos recursos de sinistros.
## Suporte de perfil e lógica de inclusão
Para PDex exportações, a `$davinci-data-export` operação usa declarações de perfil no `meta.profile` elemento para determinar quais recursos incluir na exportação.
### ExplanationOfBenefit Tratamento de recursos
`ExplanationOfBenefit`Os recursos (EOB) são incluídos ou excluídos PDex das exportações com base em suas `meta.profile` declarações:
+ ExplanationOfBenefit recursos com um perfil CARIN BB 1.x são excluídos da exportação.
+ ExplanationOfBenefit recursos sem `meta.profile` conjunto são excluídos da exportação.
+ ExplanationOfBenefit recursos com um perfil CARIN BB 2.x Basis estão sempre incluídos.
+ ExplanationOfBenefit recursos com um perfil CARIN BB 2.x que contém dados financeiros são excluídos por padrão. Quando `_includeEOB2xWoFinancial=true` definido, eles são incluídos com os dados financeiros retirados e o recurso é transformado no perfil Basis correspondente.
+ ExplanationOfBenefit recursos com um perfil de autorização PDex prévia estão sempre incluídos.
### Transformação de dados financeiros
Quando você configura`_includeEOB2xWoFinancial=true`, a operação transforma os ExplanationOfBenefit recursos do [CARIN BB 2.x](https://hl7.org/fhir/us/carin-bb/) em seus perfis Basis correspondentes, removendo dados financeiros. Por exemplo, um `C4BB ExplanationOfBenefit Oral` recurso é transformado em`C4BB ExplanationOfBenefit Oral Basis`, o que retira os dados financeiros do registro de acordo com a especificação FHIR.
Os seguintes elementos de dados financeiros são removidos durante a transformação:
+ Todos os elementos são cortados `total`
+ Todos os `adjudication` elementos com `amounttype` fatia
+ Todos os `item.adjudication` elementos com informações de quantidade
A operação também atualiza os metadados do perfil durante a transformação:
+ `meta.profile`é atualizado para o URL canônico do perfil básico
+ A versão é atualizada para a versão base do CARIN BB 2.x
+ Os recursos existentes no armazenamento de dados não são modificados
+ Os recursos exportados não são mantidos de volta ao armazenamento de dados
### Regras de detecção de perfil
A operação usa as seguintes regras para detectar e validar perfis:
+ A detecção de versão é baseada no código `meta.profile` canônico URLs
+ Um recurso é incluído se QUALQUER um de seus perfis declarados corresponder aos critérios de exportação.
+ A validação do perfil ocorre durante o processamento da exportação
## Filtragem temporal de cinco anos para exportações PDex
Para todos os tipos de PDex exportação, HealthLake aplica um filtro temporal de 5 anos com base na última atualização do recurso. O filtro temporal se aplica a todos os recursos, exceto aos seguintes tipos principais de recursos de atribuição, que são sempre exportados independentemente da idade:
+ `Patient`
+ `Coverage`
+ `Organization`
+ `Practitioner`
+ `PractitionerRole`
+ `RelatedPerson`
+ `Location`
+ `Group`
Esses recursos administrativos e demográficos são isentos porque fornecem contexto essencial para os dados exportados. As exportações de ATR não estão sujeitas a nenhuma filtragem temporal.
## Solicitações de amostra
Os exemplos a seguir mostram como iniciar trabalhos de exportação para diferentes tipos de exportação.
*Exportação ATR*
```
GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Group,Patient,Coverage,Practitioner,Organization&exportType=hl7.fhir.us.davinci-atr
POST https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Group,Patient,Coverage,Practitioner,Organization&exportType=hl7.fhir.us.davinci-atr
Content-Type: application/json
{
"DataAccessRoleArn": "arn:aws:iam::444455556666:role/your-healthlake-service-role",
"JobName": "attribution-export-job",
"OutputDataConfig": {
"S3Configuration": {
"S3Uri": "s3://your-export-bucket/EXPORT-JOB",
"KmsKeyId": "arn:aws:kms:region:444455556666:key/1234abcd-12ab-34cd-56ef-1234567890ab"
}
}
}
```
*Exportação do Provider Access com remoção de dados ExplanationOfBenefit financeiros*
```
GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Patient,Observation,Condition,MedicationRequest,ExplanationOfBenefit&exportType=hl7.fhir.us.davinci-pdex&_includeEOB2xWoFinancial=true
```
*Payer-to-Payer exportar*
```
GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Patient,Coverage,ExplanationOfBenefit,Condition,Procedure&exportType=hl7.fhir.us.davinci-pdex.p2p&_includeEOB2xWoFinancial=true
```
*Exportação de acesso de membro para um paciente específico*
```
GET https://healthlake.{region}.amazonaws.com/datastore/{datastoreId}/r4/Group/example-group/$davinci-data-export?_type=Patient,Observation,Condition,ExplanationOfBenefit,MedicationRequest&exportType=hl7.fhir.us.davinci-pdex.member&patient=Patient/example-patient-id
```
## Resposta da amostra
```
{
"datastoreId": "eaee622d8406b41eb86c0f4741201ff9",
"jobStatus": "SUBMITTED",
"jobId": "48d7b91dae4a64d00d54b70862f33f61"
}
```
## Relações de recursos
A operação exporta recursos com base em seus relacionamentos na Lista de atribuição de membros:
```
Group (Attribution List)
├── Patient (Members)
├── Coverage → RelatedPerson (Subscribers)
├── Practitioner (Attributed Providers)
├── PractitionerRole → Location
└── Organization (Attributed Providers)
```
### Fontes de recursos
| Recurso | Localização da fonte | Description |
| --- | --- | --- |
| Patient | Group.member.entity | Os pacientes que são membros da lista de atribuição |
| Coverage | Group.member.extension:coverageReference | Cobertura que resultou na adesão do paciente |
| Organization | Group.member.extension:attributedProvider | Organizações às quais os pacientes são atribuídos |
| Practitioner | Group.member.extension:attributedProvider | Profissionais individuais aos quais os pacientes são atribuídos |
| PractitionerRole | Group.member.extension:attributedProvider | Funções profissionais às quais os pacientes são atribuídos |
| RelatedPerson | Coverage.subscriber | Assinantes da cobertura |
| Location | PractitionerRole.location | Locais associados às funções dos profissionais |
| Group | Ponto final de entrada | A própria lista de atribuições |
## Gestão de Job
Verifique o status do trabalho
`GET [base]/export/[job-id]`
Cancelar trabalho
`DELETE [base]/export/[job-id]`
### Ciclo de vida da tarefa
+ `SUBMITTED`- Job foi recebido e colocado na fila
+ `IN_PROGRESS`- O trabalho está sendo processado ativamente
+ `COMPLETED`- Job concluído com sucesso, arquivos disponíveis para download
+ `FAILED`- Job encontrou um erro
## Output Format
+ *Formato de arquivo*: NDJSON (JSON delimitado por nova linha)
+ *Organização de arquivos*: arquivos separados para cada tipo de recurso
+ *Extensão do arquivo*: .ndjson
+ *Localização*: bucket e caminho do S3 especificados
## Tratamento de erros
A operação retorna HTTP 400 Bad Request com uma OperationOutcome das seguintes condições:
Erros de autorização
A função do IAM especificada em `DataAccessRoleArn` não tem permissões suficientes para realizar a operação de exportação. Para obter a lista completa das permissões necessárias do S3 e do KMS, consulte [Configuração de permissões para trabalhos de exportação](getting-started-setting-up.md#setting-up-export-permissions).
Erros de validação de parâmetros
+ O `patient` parâmetro não está formatado como `Patient/id,Patient/id,...`
+ Uma ou mais referências de pacientes são inválidas ou não pertencem ao Grupo especificado
+ O valor do `exportType` parâmetro não é um tipo de exportação compatível
+ O `_type` parâmetro contém tipos de recursos que não são compatíveis com o tipo de exportação especificado.
+ O `_type` parâmetro não contém os tipos de recursos necessários (`Group`,`Patient`,`Coverage`) para o tipo de `hl7.fhir.us.davinci-atr` exportação
+ O valor do `_includeEOB2xWoFinancial` parâmetro não é um booleano válido
Erros de validação de recursos
+ O recurso de grupo especificado não existe no armazenamento de dados
+ O recurso de grupo especificado não tem membros
+ Um ou mais membros do Grupo fazem referência a recursos do paciente que não existem no armazenamento de dados
## Segurança e autorização
+ Os mecanismos de autorização padrão do FHIR se aplicam
+ A função de acesso a dados deve ter as permissões necessárias do IAM para operações do S3 e do KMS. Para ver a lista completa das permissões necessárias, consulte [Configuração de permissões para trabalhos de exportação](getting-started-setting-up.md#setting-up-export-permissions).
## Práticas recomendadas
+ *Seleção do tipo de recurso*: solicite somente os tipos de recursos necessários para minimizar o tamanho da exportação e o tempo de processamento
+ *Filtragem baseada em tempo*: use o `_since` parâmetro para exportações incrementais
+ *Filtragem de pacientes*: use o `patient` parâmetro quando precisar apenas de dados de membros específicos
+ *Monitoramento de trabalhos*: verifique regularmente o status do trabalho para grandes exportações
+ *Tratamento de erros*: implemente a lógica de repetição adequada para trabalhos com falha
+ *Reconhecimento do filtro temporal*: para PDex exportações, considere o filtro temporal de 5 anos ao selecionar os tipos de recursos
+ *Remoção de dados financeiros*: use `_includeEOB2xWoFinancial=true` quando precisar de dados de sinistros sem informações financeiras
+ *Gerenciamento de perfil*: garanta que os recursos tenham declarações de perfil apropriadas, valide os perfis de destino antes da ingestão e use o controle de versão do perfil para controlar o comportamento de exportação
## Limitações
+ Máximo de 500 pacientes pode ser especificado no `patient` parâmetro
+ A exportação é limitada somente às operações em nível de grupo
+ Suporta apenas o conjunto predefinido de tipos de recursos para cada tipo de exportação
+ A saída está sempre no formato NDJSON
+ PDex as exportações são limitadas a 5 anos de dados clínicos e de sinistros
+ A transformação de dados financeiros só se aplica aos perfis CARIN BB 2.x ExplanationOfBenefit
## Recursos adicionais
+ [Lista de atribuição de membros da Da Vinci IG](https://build.fhir.org/ig/HL7/davinci-atr/)
+ [Intercâmbio de Dados do Jogador Da Vinci (IG)](https://hl7.org/fhir/us/davinci-pdex/)
+ [CARIN Consumer Directed Player Data Exchange IG](https://build.fhir.org/ig/HL7/carin-bb/)
+ [Guia de implementação principal dos EUA](https://www.hl7.org/fhir/us/core/)
+ [Especificação de acesso a dados em massa do FHIR](https://hl7.org/fhir/uv/bulkdata/)
# Gerando documentos clínicos com `$document`
AWS HealthLake agora suporta a `$document` operação de recursos de composição, permitindo gerar um documento clínico completo agrupando a composição com todos os recursos referenciados em um único pacote coeso. Essa operação é essencial para aplicativos de saúde que precisam:
+ Crie documentos clínicos padronizados
+ Troque registros completos de pacientes
+ Armazene documentação clínica abrangente
+ Gere relatórios que incluam todo o contexto relevante
## Usage
A `$document` operação pode ser invocada em recursos de composição usando os métodos GET e POST:
**Operações com Suporte**
```
GET/POST [base]/Composition/[id]/$document
```
## Parâmetros compatíveis
HealthLake suporta o seguinte parâmetro FHIR: `$document`
| Parâmetro | Tipo | Obrigatório | Padrão | Description |
| --- | --- | --- | --- | --- |
| persist | booliano | Não | false | Booleano indicando se o servidor deve armazenar o pacote de documentos gerado |
## Exemplos
**Solicitação GET**
```
GET [base]/Composition/180f219f-97a8-486d-99d9-ed631fe4fc57/$document?persist=true
```
**Solicitação POST com parâmetros**
```
POST [base]/Composition/180f219f-97a8-486d-99d9-ed631fe4fc57/$document
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "persist",
"valueBoolean": true
}
]
}
```
**Resposta da amostra**
A operação retorna um recurso Bundle do tipo “documento” contendo a composição e todos os recursos referenciados:
```
{
"resourceType": "Bundle",
"id": "180f219f-97a8-486d-99d9-ed631fe4fc57",
"type": "document",
"identifier": {
"system": "urn:ietf:rfc:3986",
"value": "urn:uuid:0c3151bd-1cbf-4d64-b04d-cd9187a4c6e0"
},
"timestamp": "2024-06-21T15:30:00Z",
"entry": [
{
"fullUrl": "http://example.org/fhir/Composition/180f219f-97a8-486d-99d9-ed631fe4fc57",
"resource": {
"resourceType": "Composition",
"id": "180f219f-97a8-486d-99d9-ed631fe4fc57",
"status": "final",
"type": {
"coding": [
{
"system": "http://loinc.org",
"code": "34133-9",
"display": "Summary of Episode Note"
}
]
},
"subject": {
"reference": "Patient/example"
},
"section": [
{
"title": "Allergies",
"entry": [
{
"reference": "AllergyIntolerance/123"
}
]
}
]
}
},
{
"fullUrl": "http://example.org/fhir/Patient/example",
"resource": {
"resourceType": "Patient",
"id": "example",
"name": [
{
"family": "Smith",
"given": ["John"]
}
]
}
},
{
"fullUrl": "http://example.org/fhir/AllergyIntolerance/123",
"resource": {
"resourceType": "AllergyIntolerance",
"id": "123",
"patient": {
"reference": "Patient/example"
},
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "418689008",
"display": "Allergy to penicillin"
}
]
}
}
}
]
}
```
## Comportamento
A `$document` operação:
1. Usa o recurso de composição especificado como base para o documento
1. Identifica e recupera todos os recursos diretamente referenciados pela Composição
1. Empacota a composição e todos os recursos referenciados em um pacote do tipo “documento”
1. Armazena o pacote de documentos gerado no armazenamento de dados quando o parâmetro persist é definido como verdadeiro
1. Identifica e recupera recursos referenciados indiretamente pela Composição para geração abrangente de documentos
Atualmente, a `$document` operação oferece suporte à recuperação de referências de recursos no seguinte formato:
1.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. Recurso/ID
As referências de recursos não suportadas no recurso de composição serão filtradas do documento gerado.
## Tratamento de erros
A operação trata das seguintes condições de erro:
+ 400 Solicitação inválida: `$document` operação inválida (solicitação não conforme) ou se o documento resultante falhar na validação do FHIR devido a referências filtradas quando persistir é definido como verdadeiro
+ 404 Não encontrado: recurso de composição não encontrado
Para obter mais informações sobre a especificação da `$document` operação, consulte a documentação da composição do [FHIR R4](https://www.hl7.org/fhir/R4/composition-operation-document.html). `$document`
# Removendo recursos permanentemente com `$erase`
AWS HealthLake suporta a `$erase` operação, permitindo a exclusão permanente de um recurso específico e de suas versões históricas. Essa operação é particularmente útil quando você precisa:
+ Remova permanentemente recursos individuais
+ Excluir históricos de versões específicos
+ Gerencie ciclos de vida de recursos individuais
+ Cumpra os requisitos específicos de remoção de dados
## Usage
A `$erase` operação pode ser invocada em dois níveis:
**Nível de instância do recurso**
```
POST [base]/[ResourceType]/[ID]/$erase?deleteAuditEvent=true
```
**Nível específico da versão**
```
POST [base]/[ResourceType]/[ID]/_history/[VersionID]/$erase
```
## Parâmetros
| Parâmetro | Tipo | Obrigatório | Padrão | Description |
| --- | --- | --- | --- | --- |
| deleteAuditEvent | booliano | Não | false | Quando verdadeiro, exclui os eventos de auditoria associados |
## Exemplos
**Exemplo de solicitação**
```
POST [base]/Patient/example-patient/$erase
```
**Exemplo de resposta**
```
{
"jobId": "5df47e2f51ff3c731847678cb8cad48e",
"jobStatus": "SUBMITTED"
}
```
## Status do trabalho
Para verificar o status de uma tarefa de exclusão:
```
GET [base]/$erase/[jobId]
```
A operação retorna informações sobre o status do trabalho:
```
{
"datastoreId": "36622996b1fcecb7e12ee2ee085308d3",
"jobId": "5df47e2f51ff3c731847678cb8cad48e",
"status": "COMPLETED",
"submittedTime": "2025-10-30T16:39:24.160Z"
}
```
## Comportamento
A `$erase` operação:
1. Processa de forma assíncrona para garantir a integridade dos dados
1. Mantém transações ACID
1. Fornece rastreamento do status do trabalho
1. Remove permanentemente o recurso especificado e suas versões
1. Inclui registro abrangente de auditoria das atividades de exclusão
1. Oferece suporte à exclusão seletiva de eventos de auditoria
## Registro de auditoria
A `$erase` operação é registrada DeleteResource com o ID do usuário, o carimbo de data/hora e os detalhes do recurso.
## Limitações
+ `$erased`o recurso não aparecerá nos resultados da pesquisa ou `_history` nas consultas.
+ Os recursos que estão sendo apagados podem ficar temporariamente inacessíveis durante o processamento
+ A medição de armazenamento é ajustada imediatamente à medida que os recursos são removidos permanentemente
# Obtendo dados do paciente com `Patient/$everything`
A `Patient/$everything` operação é usada para consultar um `Patient` recurso FHIR, junto com quaisquer outros recursos relacionados a ele. `Patient` A operação pode ser usada para fornecer ao paciente acesso a todo o prontuário ou para que um provedor realize um download em massa de dados relacionados a um paciente. HealthLakesuportes `Patient/$everything` para um paciente específico`id`.
`Patient/$everything`é uma operação da API FHIR REST que pode ser invocada conforme mostrado nos exemplos abaixo.
------
#### [ GET request ]
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything
```
------
**nota**
Os recursos em resposta são classificados por tipo de recurso e recurso`id`.
A resposta é sempre preenchida com`Bundle.total`.
## Parâmetros do `Patient/$everything`
HealthLake suporta os seguintes parâmetros de consulta
| Parâmetro | Detalhes |
| --- | --- |
| rápido | Obtenha todos os `Patient` dados após uma data de início especificada. |
| end | Obtenha todos os `Patient` dados antes de uma data de término especificada. |
| since | Atualize todos os `Patient` dados após uma data especificada. |
| \$1tipo | Obtenha `Patient` dados para tipos de recursos específicos. |
| \$1contar | Obtenha `Patient` dados e especifique o tamanho da página. |
**Example - Obtenha todos os dados do paciente após uma data de início especificada**
`Patient/$everything`pode usar o `start` filtro para consultar somente dados após uma data específica.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?start=2024-03-15T00:00:00.000Z
```
**Example - Obtenha todos os `Patient` dados antes de uma data de término especificada**
O paciente \$1everything pode usar o `end` filtro para consultar apenas dados antes de uma data específica.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?end=2024-03-15T00:00:00.000Z
```
**Example - Obtenha todos os `Patient` dados atualizados após uma data especificada**
`Patient/$everything`pode usar o `since` filtro para consultar somente dados atualizados após uma data específica.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?since=2024-03-15T00:00:00.000Z
```
**Example - Obtenha `Patient` dados para tipos de recursos específicos**
O paciente \$1everything pode usar o `_type` filtro para especificar tipos de recursos específicos a serem incluídos na resposta. Vários tipos de recursos podem ser especificados em uma lista separada por vírgulas.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?_type=Observation,Condition
```
**Example - Obtenha `Patient` dados e especifique o tamanho da página**
O paciente \$1everything pode usar o `_count` para definir o tamanho da página.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?_count=15
```
## `Patient/$everything``start`e `end` atributos
HealthLake oferece suporte aos seguintes atributos de recursos para `Patient/ $everything` `start` os parâmetros de `end` consulta e.
| Recurso | Elemento de recursos |
| --- | --- |
| Conta | conta.período de serviço. Início |
| AdverseEvent | AdverseEvent.data |
| AllergyIntolerance | AllergyIntolerance.Data de gravação |
| Nomeação | Marcação. Início |
| AppointmentResponse | AppointmentResponse.iniciar |
| AuditEvent | AuditEvent.periodo.start |
| Básico | Básico. Criado |
| BodyStructure | SEM DATA |
| CarePlan | CarePlan.periodo.start |
| CareTeam | CareTeam.periodo.start |
| ChargeItem | ChargeItem. occurrenceDateTime, ChargeItem .OccurrencePeriod.start, .OccurrenceTiming.Event ChargeItem |
| Reivindicar | Reivindicação. Período faturável. Início |
| ClaimResponse | ClaimResponse.criado |
| ClinicalImpression | ClinicalImpression.data |
| Comunicação | Comunicação. Enviada |
| CommunicationRequest | CommunicationRequest. occurrenceDateTime, .Período de CommunicationRequest ocorrência.Início |
| Composição | Composição.Data |
| Condição | Condição.Data de gravação |
| Consentimento | Consentimento.Data/hora |
| Cobertura | Cobertura.Período.Início |
| CoverageEligibilityRequest | CoverageEligibilityRequest.criado |
| CoverageEligibilityResponse | CoverageEligibilityResponse.criado |
| DetectedIssue | DetectedIssue.identificado |
| DeviceRequest | DeviceRequest.Autor Edon |
| DeviceUseStatement | DeviceUseStatement. Gravado em |
| DiagnosticReport | DiagnosticReport.eficaz |
| DocumentManifest | DocumentManifest.criado |
| DocumentReference | DocumentReference.contexto.period.start |
| Encontro | Encounter.period.start |
| EnrollmentRequest | EnrollmentRequest.criado |
| EpisodeOfCare | EpisodeOfCare.periodo.start |
| ExplanationOfBenefit | ExplanationOfBenefit.Período faturável. Início |
| FamilyMemberHistory | SEM DATA |
| Sinalizador | FLAG.PERIOD.START |
| Objetivo | Objetivo.StatusData |
| Group (Grupo) | SEM DATA |
| ImagingStudy | ImagingStudy.iniciado |
| Imunização | Imunização. Registrada |
| ImmunizationEvaluation | ImmunizationEvaluation.data |
| ImmunizationRecommendation | ImmunizationRecommendation.data |
| Fatura | Data da fatura |
| Lista | Data da lista |
| MeasureReport | MeasureReport.periodo.start |
| Mídia | Mídia. Emitido |
| MedicationAdministration | MedicationAdministration.eficaz |
| MedicationDispense | MedicationDispense. Quando preparado |
| MedicationRequest | MedicationRequest.Autor Edon |
| MedicationStatement | MedicationStatement.Data declarada |
| MolecularSequence | SEM DATA |
| NutritionOrder | NutritionOrder.Data/hora |
| Observação | Observação. Eficaz |
| Paciente | SEM DATA |
| Pessoa | SEM DATA |
| Procedimento | Procedimento. Executado |
| Proveniência | Proveniência. Período ocorrido. Início, Proveniência. occurredDateTime |
| QuestionnaireResponse | QuestionnaireResponse.de autoria |
| RelatedPerson | SEM DATA |
| RequestGroup | RequestGroup.Autor Edon |
| ResearchSubject | ResearchSubject.período |
| RiskAssessment | RiskAssessment. occurrenceDateTime, .Período de RiskAssessment ocorrência.Início |
| Agendamento | Cronograma. Horizonte de planejamento |
| ServiceRequest | ServiceRequest.Autor Edon |
| Espécime | Espécime. Hora recebida |
| SupplyDelivery | SupplyDelivery. occurrenceDateTime, SupplyDelivery .OccurrencePeriod.start, .OccurrenceTiming.Event SupplyDelivery |
| SupplyRequest | SupplyRequest.Autor Edon |
| VisionPrescription | VisionPrescription.Data escrita |
# Recuperando ValueSet códigos com `$expand`
AWS HealthLake agora suporta a `$expand` operação ValueSets que foi ingerida por você como cliente, permitindo que você recupere a lista completa de códigos contidos nesses ValueSet recursos. Essa operação é particularmente útil quando você precisa:
+ Recupere todos os códigos possíveis para fins de validação
+ Exibir as opções disponíveis nas interfaces de usuário
+ Realize pesquisas abrangentes de código dentro de um contexto terminológico específico
## Usage
A `$expand` operação pode ser invocada em ValueSet recursos usando os métodos GET e POST:
**Operações com Suporte**
```
GET/POST [base]/ValueSet/[id]/$expand
GET [base]/ValueSet/$expand?url=http://example.com
POST [base]/ValueSet/$expand
```
## Parâmetros compatíveis
HealthLake suporta um subconjunto de parâmetros FHIR R4: `$expand`
| Parâmetro | Tipo | Obrigatório | Description |
| --- | --- | --- | --- |
| url | uri | Não | URL canônico do para expandir ValueSet |
| id | id | Não | ValueSet ID do recurso a ser expandido (para operações GET ou POST) |
| filter | string | Não | Filtrar o resultado da expansão do código |
| count | integer | Não | Número de códigos a serem devolvidos |
| offset | integer | Não | Número de códigos correspondentes a serem ignorados antes de devolver. Aplica-se após a filtragem e somente aos códigos correspondentes, não ao conteúdo completo e não filtrado do original ValueSet |
## Exemplos
**Solicitação GET por ID**
```
GET [base]/ValueSet/example-valueset/$expand
```
**Solicitação GET por URL com filtro**
```
GET [base]/ValueSet/$expand?url=http://example.com/ValueSet/my-valueset&filter=male&count=5
```
**Solicitação POST com parâmetros (por ID)**
```
POST [base]/ValueSet/example-valueset/$expand
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "count",
"valueInteger": 10
},
{
"name": "filter",
"valueString": "admin"
}
]
}
```
**Solicitação POST com parâmetros (por URL)**
```
POST [base]/ValueSet/$expand
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "url",
"valueUri": "http://hl7.org/fhir/ValueSet/administrative-gender"
},
{
"name": "count",
"valueInteger": 10
}
]
}
```
**Resposta da amostra**
A operação retorna um ValueSet recurso com um `expansion` elemento contendo os códigos expandidos:
```
{
"resourceType": "ValueSet",
"id": "administrative-gender",
"status": "active",
"expansion": {
"identifier": "urn:uuid:12345678-1234-1234-1234-123456789abc",
"timestamp": "2024-01-15T10:30:00Z",
"total": 4,
"parameter": [
{
"name": "count",
"valueInteger": 10
}
],
"contains": [
{
"system": "http://hl7.org/fhir/administrative-gender",
"code": "male",
"display": "Male"
},
{
"system": "http://hl7.org/fhir/administrative-gender",
"code": "female",
"display": "Female"
},
{
"system": "http://hl7.org/fhir/administrative-gender",
"code": "other",
"display": "Other"
},
{
"system": "http://hl7.org/fhir/administrative-gender",
"code": "unknown",
"display": "Unknown"
}
]
}
}
```
A resposta inclui:
+ expansion.total: número total de códigos no expandido ValueSet
+ expansion.contains: matriz de códigos expandidos com seus valores de sistema, código e exibição
+ expansion.parameter: parâmetros usados na solicitação de expansão
Para obter mais informações sobre a especificação da `$expand` operação, consulte a documentação do [FHIR ValueSet `$expand` R4](https://build.fhir.org/valueset-operation-expand.html).
# Exportação de HealthLake dados com o FHIR `$export`
Você pode exportar dados em massa do seu armazenamento de HealthLake dados usando a operação FHIR \$1export. HealthLake suporta o `$export` uso `POST` e as solicitações do FHIR. `GET` Para fazer uma solicitação de exportação com`POST`, você precisa ter um usuário, grupo ou função do IAM com as permissões necessárias, especificar `$export` como parte da solicitação e incluir os parâmetros desejados no corpo da solicitação.
**nota**
Todas as solicitações de HealthLake exportação feitas usando o FHIR `$export` são retornadas em `ndjson` formato e exportadas para um bucket do Amazon S3, onde cada objeto do Amazon S3 contém somente um único tipo de recurso do FHIR.
Você pode enfileirar solicitações de exportação de acordo com as AWS cotas de serviço da conta. Para obter mais informações, consulte [Cotas de serviço](reference-healthlake-endpoints-quotas.md#reference-healthlake-quotas).
HealthLake suporta os três tipos de solicitações de endpoint de exportação em massa a seguir.
**HealthLake `$export`tipos a granel**
| Tipo de exportação | Description | Sintaxe |
| --- | --- | --- |
| Sistema | Exporte todos os dados do servidor HealthLake FHIR. | `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/$export` |
| Todos os pacientes | Exporte todos os dados relacionados a todos os pacientes, incluindo os tipos de recursos associados ao tipo de recurso do paciente. | `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/$export` `GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/$export` |
| Grupo de pacientes | Exporte todos os dados relacionados a um grupo de pacientes especificado com uma ID de grupo. | `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Group/id/$export` `GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Group/id/$export` |
## Antes de começar
Atenda aos requisitos a seguir para fazer uma solicitação de exportação usando a API FHIR REST para. HealthLake
+ Você deve ter configurado um usuário, grupo ou função que tenha as permissões necessárias para fazer a solicitação de exportação. Para saber mais, consulte [Autorizando uma solicitação `$export`](#export-rest-auth).
+ Você deve ter criado uma função de serviço que conceda HealthLake acesso ao bucket do Amazon S3 para o qual você deseja que seus dados sejam exportados. A função de serviço também deve ser especificada HealthLake como principal do serviço. Para obter mais informações sobre a configuração de permissões, consulte[Configurando permissões para trabalhos de exportação](getting-started-setting-up.md#setting-up-export-permissions).
## Autorizando uma solicitação `$export`
Para fazer uma solicitação de exportação bem-sucedida usando a API REST FHIR, autorize seu usuário, grupo ou função usando IAM ou .0. OAuth2 Você também deve ter uma função de serviço.
**Autorizar uma solicitação usando o IAM**
Quando você faz uma `$export` solicitação, o usuário, o grupo ou a função devem ter ações do IAM incluídas na política. Para obter mais informações, consulte [Configurando permissões para trabalhos de exportação](getting-started-setting-up.md#setting-up-export-permissions).
**Autorizando uma solicitação usando SMART no FHIR (2.0) OAuth**
Ao fazer uma `$export` solicitação em um SMART no armazenamento de HealthLake dados habilitado para FHIR, você deve ter os escopos apropriados atribuídos. Para obter mais informações, consulte [SMART nos escopos de recursos do FHIR para HealthLake](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest).
**nota**
O FHIR `$export` com `GET` solicitações exige o mesmo método de autenticação ou token do portador (no caso do SMART no FHIR) para solicitar a exportação e a recuperação de arquivos. Os arquivos exportados usando o FHIR `$export` com `GET` estão disponíveis para download por 48 horas.
## Fazendo uma `$export` solicitação
Esta seção descreve as etapas necessárias que você deve seguir ao fazer uma solicitação de exportação usando a API FHIR REST.
Para evitar cobranças acidentais em sua AWS conta, recomendamos testar suas solicitações fazendo uma `POST` solicitação sem fornecer a `$export` sintaxe.
Para fazer a solicitação, você deve fazer o seguinte:
1. Especifique `$export` no URL da `POST` solicitação para um endpoint compatível.
1. Especifique os parâmetros de cabeçalho necessários.
1. Especifique um corpo de solicitação que defina os parâmetros necessários.
### Etapa 1: especifique `$export` no URL da `POST` solicitação para um [endpoint](reference-healthlake-endpoints-quotas.md#reference-healthlake-endpoints) compatível.
HealthLake oferece suporte a três tipos de solicitações de endpoint de exportação em massa. Para fazer uma solicitação de exportação em massa, você deve fazer uma solicitação `POST` com base em um dos três endpoints compatíveis. Os exemplos a seguir demonstram onde especificar `$export` na URL da solicitação.
+ `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/$export`
+ `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/$export`
+ `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Group/id/$export`
Você pode usar os seguintes parâmetros de pesquisa compatíveis na string de `POST` solicitação.
#### Parâmetros de pesquisa compatíveis
HealthLake suporta os seguintes modificadores de pesquisa em solicitações de exportação em massa.
Os exemplos a seguir incluem caracteres especiais que devem ser codificados antes de enviar sua solicitação.
| Nome | Obrigatório? | Description | Exemplo |
| --- | --- | --- | --- |
| \$1outputFormat | Não | O formato dos arquivos de dados em massa solicitados a serem gerados. Os valores aceitos sãoapplication/fhir\$1ndjson,application/ndjson,ndjson. | |
| \$1type | Não | Uma sequência de tipos de recursos FHIR delimitados por vírgula que você deseja incluir em seu trabalho de exportação. Recomendamos incluir \$1type porque isso pode ter uma implicação de custo quando todos os recursos são exportados. | &\$1type=MedicationStatement, Observation |
| \$1since | Não | Tipos de recursos modificados em ou após o carimbo de data e hora. Se um tipo de recurso não tiver um horário de última atualização, ele será incluído na sua resposta. | &\$1since=2024-05-09T00%3A00%3A00Z |
| \$1until | Não | Tipos de recursos modificados em ou antes do carimbo de data e hora. Usado em combinação com \$1since para definir um intervalo de tempo específico para exportação. Se um tipo de recurso não tiver um horário de última atualização, ele será excluído da sua resposta. | &\$1until=2024-12-31T23%3A59%3A59Z |
### Etapa 2: especificar os parâmetros de cabeçalho necessários
Para fazer uma solicitação de exportação usando a API REST FHIR, você deve especificar os seguintes parâmetros de cabeçalho.
+ Content-Type: `application/fhir+json`
+ Prefiro: `respond-async`
Em seguida, você deve especificar os elementos necessários no corpo da solicitação.
### Etapa 3: especifique um corpo de solicitação que defina os parâmetros necessários.
A solicitação de exportação também exige um corpo em `JSON` formato. O corpo pode incluir os seguintes parâmetros.
| Chave | Obrigatório? | Description | Valor |
| --- | --- | --- | --- |
| DataAccessRoleArn | Sim | Um ARN de uma função de HealthLake serviço. A função de serviço usada deve ser especificada HealthLake como principal do serviço. | arn:aws:iam::444455556666:role/your-healthlake-service-role |
| JobName | Não | O nome da solicitação de exportação. | your-export-job-name |
| S3Uri | Sim | Parte de uma OutputDataConfig chave. O URI do S3 do bucket de destino em que seus dados exportados serão baixados. | s3://amzn-s3-demo-bucket/EXPORT-JOB/ |
| KmsKeyId | Sim | Parte de uma OutputDataConfig chave. O ARN da AWS KMS chave usada para proteger o bucket do Amazon S3. | arn:aws:kms:region-of-bucket:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab |
**Example Corpo de uma solicitação de exportação feita usando a API FHIR REST**
Para fazer uma solicitação de exportação usando a API REST FHIR, você deve especificar um corpo, conforme mostrado a seguir.
```
{
"DataAccessRoleArn": "arn:aws:iam::444455556666:role/your-healthlake-service-role",
"JobName": "your-export-job",
"OutputDataConfig": {
"S3Configuration": {
"S3Uri": "s3://amzn-s3-demo-bucket/EXPORT-JOB",
"KmsKeyId": "arn:aws:kms:region-of-bucket:444455556666:key/1234abcd-12ab-34cd-56ef-1234567890ab"
}
}
}
```
Quando sua solicitação for bem-sucedida, você receberá a seguinte resposta.
*cabeçalho de resposta*
```
content-location: https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-job-id
```
*Corpo de resposta*
```
{
"datastoreId": "your-data-store-id",
"jobStatus": "SUBMITTED",
"jobId": "your-export-request-job-id"
}
```
## Gerenciando sua solicitação de exportação
Depois de fazer uma solicitação de exportação bem-sucedida, você pode gerenciar a solicitação usando `$export` para descrever o status de uma solicitação de exportação atual e `$export` cancelar uma solicitação de exportação atual.
Ao cancelar uma solicitação de exportação usando a API REST, você só é cobrado pela parte dos dados que foram exportados até o momento em que você enviou a solicitação de cancelamento.
Os tópicos a seguir descrevem como você pode obter o status de uma solicitação de exportação atual ou cancelá-la.
### Cancelamento de uma solicitação de exportação
Para cancelar uma solicitação de exportação, faça uma `DELETE` solicitação e forneça o ID do trabalho na URL da solicitação.
```
DELETE https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-job-id
```
Quando sua solicitação for bem-sucedida, você receberá o seguinte.
```
{
"exportJobProperties": {
"jobId": "your-original-export-request-job-id",
"jobStatus": "CANCEL_SUBMITTED",
"datastoreId": "your-data-store-id"
}
}
```
Quando sua solicitação não for bem-sucedida, você receberá o seguinte.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-supported",
"diagnostics": "Interaction not supported."
}
]
}
```
### Descrever uma solicitação de exportação
Para obter o status de uma solicitação de exportação, faça uma `GET` solicitação usando `export` e seu`export-request-job-id`.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-id
```
A resposta JSON conterá um `ExportJobProperties` objeto. Ele pode conter os seguintes pares chave-valor.
| Nome | Obrigatório? | Description | Valor |
| --- | --- | --- | --- |
| DataAccessRoleArn | Não | Um ARN de uma função de HealthLake serviço. A função de serviço usada deve ser especificada HealthLake como principal do serviço. | arn:aws:iam::444455556666:role/your-healthlake-service-role |
| SubmitTime | Não | A data e hora em que um trabalho de exportação foi enviado. | Apr 21, 2023 5:58:02 |
| EndTime | Não | A hora em que um trabalho de exportação foi concluído. | Apr 21, 2023 6:00:08 PM |
| JobName | Não | O nome da solicitação de exportação. | your-export-job-name |
| JobStatus | Não | | Os valores válidos são:SUBMITTED | IN_PROGRESS | COMPLETED_WITH_ERRORS | COMPLETED |
FAILED
|
| S3Uri | Sim | Parte de um [OutputDataConfig](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_OutputDataConfig.html)objeto. O URI do Amazon S3 do bucket de destino em que seus dados exportados serão baixados. | s3://amzn-s3-demo-bucket/EXPORT-JOB/ |
| KmsKeyId | Sim | Parte de um [OutputDataConfig](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_OutputDataConfig.html)objeto. O ARN da AWS KMS chave usada para proteger o bucket do Amazon S3. | arn:aws:kms:region-of-bucket:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab |
**Example : Corpo de uma solicitação de descrição de exportação feita usando a API REST FHIR**
Quando for bem-sucedido, você receberá a seguinte resposta JSON.
```
{
"exportJobProperties": {
"jobId": "your-export-request-id",
"JobName": "your-export-job",
"jobStatus": "SUBMITTED",
"submitTime": "Apr 21, 2023 5:58:02 PM",
"endTime": "Apr 21, 2023 6:00:08 PM",
"datastoreId": "your-data-store-id",
"outputDataConfig": {
"s3Configuration": {
"S3Uri": "s3://amzn-s3-demo-bucket/EXPORT-JOB",
"KmsKeyId": "arn:aws:kms:region-of-bucket:444455556666:key/1234abcd-12ab-34cd-56ef-1234567890ab""
}
},
"DataAccessRoleArn": "arn:aws:iam::444455556666:role/your-healthlake-service-role",
}
}
```
# Operação FHIR para `$inquire` HealthLake
A `$inquire` operação permite que você verifique o status de uma solicitação de autorização prévia enviada anteriormente. Essa operação implementa o [Guia de Implementação do Da Vinci Prior Authorization Support (PAS)](https://hl7.org/fhir/us/davinci-pas/), fornecendo um fluxo de trabalho padronizado baseado em FHIR para recuperar a decisão de autorização atual.
## Como funciona
+ **Enviar consulta**: Você envia um pacote FHIR contendo a reclamação que deseja verificar e informações de apoio
+ **Pesquisa**: HealthLake pesquisa o correspondente ClaimResponse em seu armazenamento de dados
+ **Recuperar**: o status de autorização mais recente foi recuperado
+ **Responder**: você recebe uma resposta imediata com o status atual da autorização (em fila, aprovada, negada etc.)
**nota**
`$inquire`é uma **operação somente de leitura** que recupera o status de autorização existente. Ele não modifica nem atualiza nenhum recurso em seu armazenamento de dados.
## Ponto final da API
```
POST /datastore/{datastoreId}/r4/Claim/$inquire
Content-Type: application/fhir+json
```
## Estrutura de solicitações
### Requisitos do pacote
Sua solicitação deve ser um recurso do FHIR Bundle com:
+ **Bundle.type**: Deve ser `"collection"`
+ **Bundle.entry**: deve conter exatamente **um** recurso de reivindicação com:
+ `use = "preauthorization"`
+ `status = "active"`
+ **Recursos referenciados**: todos os recursos referenciados pela reivindicação devem ser incluídos no pacote
**Consulta por exemplo**
Os recursos em seu pacote de entrada servem como um modelo de pesquisa. HealthLake usa as informações fornecidas para localizar o correspondente ClaimResponse.
### Recursos necessários
| Recurso | Cardinalidade | Perfil | Description |
| --- | --- | --- | --- |
| Reclamação | 1 | Consulta de reclamação do PAS | A autorização prévia sobre a qual você está perguntando |
| Paciente | 1 | Paciente beneficiário do PAS | Informações demográficas do paciente |
| Organização (Seguradora) | 1 | Organização seguradora PAS | Companhia de seguros |
| Organização (Provedor) | 1 | Organização solicitante do PAS | Profissional de saúde que enviou a solicitação |
### Critérios de pesquisa importantes
HealthLake pesquisa o ClaimResponse uso de:
+ **Referência do paciente** a partir da reclamação
+ **Referência da seguradora** a partir da reclamação
+ **Referência do provedor** a partir da reclamação
+ **Data de criação** a partir da reclamação (como filtro de tempo)
**Somente consultas específicas do paciente**
Todas as consultas devem estar vinculadas a um paciente específico. Consultas em todo o sistema sem identificação do paciente não são permitidas.
## Exemplo de solicitação
```
POST /datastore/example-datastore/r4/Claim/$inquire
Content-Type: application/fhir+json
Authorization: Bearer
{
"resourceType": "Bundle",
"id": "PASClaimInquiryBundleExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-pas-inquiry-request-bundle"]
},
"identifier": {
"system": "http://example.org/SUBMITTER_TRANSACTION_IDENTIFIER",
"value": "5269368"
},
"type": "collection",
"timestamp": "2005-05-02T14:30:00+05:00",
"entry": [
{
"fullUrl": "http://example.org/fhir/Claim/MedicalServicesAuthorizationExample",
"resource": {
"resourceType": "Claim",
"id": "MedicalServicesAuthorizationExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim-inquiry"]
},
"status": "active",
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/claim-type",
"code": "professional"
}]
},
"use": "preauthorization",
"patient": {
"reference": "Patient/SubscriberExample"
},
"created": "2005-05-02T11:01:00+05:00",
"insurer": {
"reference": "Organization/InsurerExample"
},
"provider": {
"reference": "Organization/UMOExample"
}
}
},
{
"fullUrl": "http://example.org/fhir/Patient/SubscriberExample",
"resource": {
"resourceType": "Patient",
"id": "SubscriberExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-beneficiary"]
},
"name": [{
"family": "SMITH",
"given": ["JOE"]
}],
"gender": "male"
}
},
{
"fullUrl": "http://example.org/fhir/Organization/UMOExample",
"resource": {
"resourceType": "Organization",
"id": "UMOExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor"]
},
"name": "Provider Organization"
}
},
{
"fullUrl": "http://example.org/fhir/Organization/InsurerExample",
"resource": {
"resourceType": "Organization",
"id": "InsurerExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer"]
},
"name": "Insurance Company"
}
}
]
}
```
## Formato de resposta
### Resposta de sucesso (200 OK)
Você receberá um pacote de respostas de consulta do PAS contendo:
+ **ClaimResponse**com o status de autorização atual; múltiplo **ClaimResponse**se corresponder aos critérios de pesquisa
+ Todos os recursos originais de sua solicitação (repetidos de volta)
+ Registro de data e hora de quando a resposta foi montada
**Possíveis ClaimResponse resultados**
| Outcome | Description |
| --- | --- |
| queued | A solicitação de autorização ainda está pendente de análise |
| complete | A decisão de autorização foi tomada (verifique se foi disposition aprovada/negada) |
| error | Ocorreu um erro durante o processamento |
| partial | Autorização parcial concedida |
```
{
"resourceType": "Bundle",
"identifier": {
"system": "http://example.org/SUBMITTER_TRANSACTION_IDENTIFIER",
"value": "5269367"
},
"type": "collection",
"timestamp": "2005-05-02T14:30:15+05:00",
"entry": [
{
"fullUrl": "http://example.org/fhir/ClaimResponse/InquiryResponseExample",
"resource": {
"resourceType": "ClaimResponse",
"id": "InquiryResponseExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claimresponse-inquiry"]
},
"status": "active",
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/claim-type",
"code": "professional"
}]
},
"use": "preauthorization",
"patient": {
"reference": "Patient/SubscriberExample"
},
"created": "2005-05-02T11:05:00+05:00",
"insurer": {
"reference": "Organization/InsurerExample"
},
"request": {
"reference": "Claim/MedicalServicesAuthorizationExample"
},
"outcome": "complete",
"disposition": "Approved",
"preAuthRef": "AUTH12345"
}
},
{
"fullUrl": "http://example.org/fhir/Claim/MedicalServicesAuthorizationExample",
"resource": {
"resourceType": "Claim",
"id": "MedicalServicesAuthorizationExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim-inquiry"]
},
"status": "active",
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/claim-type",
"code": "professional"
}]
},
"use": "preauthorization",
"patient": {
"reference": "Patient/SubscriberExample"
},
"created": "2005-05-02T11:01:00+05:00",
"insurer": {
"reference": "Organization/InsurerExample"
},
"provider": {
"reference": "Organization/UMOExample"
}
}
},
{
"fullUrl": "http://example.org/fhir/Patient/SubscriberExample",
"resource": {
"resourceType": "Patient",
"id": "SubscriberExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-beneficiary"]
},
"name": [{
"family": "SMITH",
"given": ["JOE"]
}],
"gender": "male"
}
},
{
"fullUrl": "http://example.org/fhir/Organization/UMOExample",
"resource": {
"resourceType": "Organization",
"id": "UMOExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor"]
},
"name": "Provider Organization"
}
},
{
"fullUrl": "http://example.org/fhir/Organization/InsurerExample",
"resource": {
"resourceType": "Organization",
"id": "InsurerExample",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer"]
},
"name": "Insurance Company"
}
}
]
}
```
## Respostas de erro
### 400 solicitação inválida
Retornado quando o formato da solicitação é inválido ou a validação falha.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "required",
"diagnostics": "Reference 'Patient/SubscriberExample' at path 'patient' for 'CLAIM' resource not found(at Bundle.entry[0].resource)"
}
]
}
```
### 401 Não autorizado
Retornado quando as credenciais de autenticação estão ausentes ou são inválidas.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "forbidden",
"diagnostics": "Invalid authorization header"
}
]
}
```
### 403 proibido
Retornado quando o usuário autenticado não tem permissão para acessar o recurso solicitado.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "exception",
"diagnostics": "Insufficient SMART scope permissions."
}
]
}
```
### 400 Quando nenhum foi encontrado
Retornado quando nenhuma correspondência ClaimResponse foi encontrada para a consulta.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "not-found",
"diagnostics": "Resource not found. No ClaimResponse found from the input Claim that matches the specified Claim properties patient, insurer, provider, and created(at Bundle.entry[0].resource)"
}]
}
```
### 415 Tipo de mídia não suportado
Retornado quando o cabeçalho Content-Type não é application/fhir\$1json.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "value",
"diagnostics": "Incorrect MIME-type. Update request Content-Type header."
}]
}
```
### 429, muitas solicitações
Retornado quando os limites de taxa são excedidos.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "throttled",
"diagnostics": "Rate limit exceeded. Please retry after some time."
}]
}
```
## Regras de validação
HealthLake realiza uma validação abrangente em sua consulta:
### Validação do pacote
+ Deve estar em conformidade com o perfil do PAS Inquiry Request Bundle
+ `Bundle.type`deve ser `"collection"`
+ Deve conter exatamente um recurso de reclamação
+ Todos os recursos referenciados devem ser incluídos no pacote
### Validação da solicitação
+ Deve estar em conformidade com o perfil PAS Claim Inquiry
+ `Claim.use`deve ser `"preauthorization"`
+ `Claim.status`deve ser `"active"`
+ Campos obrigatórios:`patient`,`insurer`,`provider`, `created`
### Validação de recursos
+ Todos os recursos devem estar em conformidade com seus respectivos perfis de consulta do PAS
+ Os recursos de apoio necessários devem estar presentes (paciente, seguradora, organização prestadora)
+ As referências cruzadas devem ser válidas e solucionáveis dentro do pacote
## Especificações de performance
| Métrica | Especificação |
| --- | --- |
| Limite de contagem de recursos | 500 recursos por pacote |
| Limite de tamanho do pacote | Máximo de 5 MB |
## Permissões obrigatórias
Para usar a `$inquire` operação, certifique-se de que sua função do IAM tenha:
+ `healthlake:InquirePreAuthClaim`- Para chamar a operação
**SMART em escopos FHIR**
**Escopos mínimos exigidos:**
+ **SMART v1:** `user/ClaimResponse.read`
+ **SMART v2:** `user/ClaimResponse.s`
## Notas de implementação importantes
### Comportamento de pesquisa
Quando você envia uma consulta, HealthLake pesquisa ClaimResponse usando:
+ **Referência do paciente** a partir da reivindicação de entrada
+ **Referência da seguradora** a partir da reclamação de entrada
+ **Referência do provedor** a partir da reivindicação de entrada
+ **Data de criação** a partir da declaração de entrada (como um filtro de tempo)
**Várias correspondências**: se várias ClaimResponses corresponderem aos seus critérios de pesquisa, HealthLake retornará todos os resultados correspondentes. Você deve usar o `ClaimResponse.created` carimbo de data/hora mais recente para identificar o status mais recente.
### Reivindicações atualizadas
Se você enviou várias atualizações para a mesma autorização anterior (por exemplo, Claim v1.1, v1.2, v1.3), a `$inquire` operação recuperará a versão ClaimResponse associada à **versão mais recente** com base nos critérios de pesquisa fornecidos.
### Operação somente de leitura
A `$inquire` operação:
+ **Recupera o** status de autorização existente
+ **Retorna o mais recente** ClaimResponse
+ **Não** modifica nem atualiza nenhum recurso
+ **Não** cria novos recursos
+ **Não** aciona o processamento de novas autorizações
## Exemplo de fluxo de trabalho
**Fluxo de trabalho típico de consulta de autorização prévia**
```
1. Provider submits PA request
POST /Claim/$submit
→ Returns ClaimResponse with outcome="queued"
2. Payer reviews request (asynchronous)
→ Updates ClaimResponse status internally
3. Provider checks status
POST /Claim/$inquire
→ Returns ClaimResponse with outcome="queued" (still pending)
4. Provider checks status again later
POST /Claim/$inquire
→ Returns ClaimResponse with outcome="complete", disposition="Approved"
```
## Operações do relacionadas
+ `Claim/$submit`- Envie uma nova solicitação de autorização prévia ou atualize uma existente
+ `Patient/$everything`- Recupere dados abrangentes do paciente para contexto de autorização prévia
# Recuperando detalhes do conceito com `$lookup`
AWS HealthLake agora suporta a `$lookup` operação de CodeSystem recursos, permitindo que você recupere detalhes sobre um conceito específico em um sistema de código fornecendo informações de identificação, como seu código. Essa operação é particularmente útil quando você precisa:
+ Recupere informações detalhadas sobre códigos médicos específicos
+ Valide os significados e propriedades do código
+ Acesse definições e relacionamentos de conceitos
+ Support a tomada de decisões clínicas com dados terminológicos precisos
## Usage
A `$lookup` operação pode ser invocada em CodeSystem recursos usando os métodos GET e POST:
**Operações com Suporte**
```
GET [base]/CodeSystem/$lookup?system=http://snomed.info/sct&code=73211009&version=20230901
POST [base]/CodeSystem/$lookup
```
## Parâmetros compatíveis
HealthLake suporta um subconjunto de parâmetros FHIR R4: `$lookup`
| Parâmetro | Tipo | Obrigatório | Description |
| --- | --- | --- | --- |
| code | código | Sim | O código conceitual que você está procurando (por exemplo, “71620000" no SNOMED CT) |
| system | uri | Sim | O URL canônico do sistema de código (por exemplo, "[http://snomed.info/sct](http://snomed.info/sct) “) |
| version | string | Não | Versão específica do sistema de código |
## Exemplos
**Solicitação GET**
```
GET [base]/CodeSystem/$lookup?system=http://snomed.info/sct&code=71620000&version=2023-09
```
**Solicitação POST**
```
POST [base]/CodeSystem/$lookup
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "system",
"valueUri": "http://snomed.info/sct"
},
{
"name": "code",
"valueCode": "71620000"
},
{
"name": "version",
"valueString": "2023-09"
}
]
}
```
**Resposta da amostra**
A operação retorna um recurso de Parâmetros contendo os detalhes do conceito:
```
{
"resourceType": "Parameters",
"parameter": [{
"name": "name",
"valueString": "SNOMED CT Fractures"
},
{
"name": "version",
"valueString": "2023-09"
},
{
"name": "display",
"valueString": "Fracture of femur"
},
{
"name": "property",
"part": [{
"name": "code",
"valueCode": "child"
},
{
"name": "value",
"valueCode": "263225007"
},
{
"name": "description",
"valueString": "Fracture of neck of femur"
}
]
},
{
"name": "property",
"part": [{
"name": "code",
"valueCode": "child"
},
{
"name": "value",
"valueCode": "263227004"
},
{
"name": "description",
"valueString": "Fracture of shaft of femur"
}
]
}
]
}
```
## Parâmetros de resposta
A resposta inclui os seguintes parâmetros, quando disponíveis:
| Parâmetro | Tipo | Description |
| --- | --- | --- |
| name | string | Nome do sistema de código |
| version | string | Versão do sistema de código |
| display | string | Nome de exibição do conceito |
| designation | BackboneElement | Representações adicionais para esse conceito. |
| property | BackboneElement | Propriedades adicionais do conceito (definição, relacionamentos, etc.) |
## Comportamento
A `$lookup` operação:
1. Valida os parâmetros necessários (`code`e`system`)
1. Pesquisa o conceito dentro do sistema de código especificado armazenado no armazenamento de dados
1. Retorna informações detalhadas do conceito, incluindo nome de exibição, designações e propriedades.
1. Suporta pesquisas específicas da versão quando o parâmetro é fornecido `version`
1. Opera somente em sistemas de código armazenados explicitamente no armazenamento de HealthLake dados
## Tratamento de erros
A operação trata das seguintes condições de erro:
+ 400 Solicitação inválida: `$lookup` operação inválida (solicitação não conforme ou ausência de parâmetros obrigatórios)
+ 404 Não encontrado: sistema de código não encontrado ou código não encontrado no sistema de código especificado
## Advertências
Para esta versão, não há suporte para o seguinte:
+ `$lookup`operação chamando servidores de terminologia externos
+ `$lookup`operação CodeSystems gerenciada por HealthLake , mas não armazenada explicitamente no armazenamento de dados
Para obter mais informações sobre a especificação da `$lookup` operação, consulte a documentação do [FHIR CodeSystem `$lookup` R4](https://www.hl7.org/fhir/R4/codesystem-operation-lookup.html).
# `$member-add`operação para HealthLake
A `$member-add` operação FHIR adiciona um membro (paciente) a um recurso do Grupo, especificamente uma Lista de Atribuição de Membros. Essa operação faz parte do Guia de Implementação de Atribuição de DaVinci Membros e apoia o processo de reconciliação para gerenciar as atribuições de membros.
## Ponto final da operação
```
POST [base]/datastore/{datastoreId}/r4/Group/{groupId}/$member-add
Content-Type: application/json
```
## Parâmetros
A operação aceita um recurso de parâmetros FHIR com as seguintes combinações de parâmetros:
### Opções de parâmetros
Você pode usar uma das seguintes combinações de parâmetros:
Opção 1: ID de membro \$1 NPI do provedor
`memberId` \$1 `providerNpi`
`memberId` \$1 `providerNpi` \$1 `attributionPeriod`
Opção 2: Referência do paciente \$1 Referência do provedor
`patientReference` \$1 `providerReference`
`patientReference` \$1 `providerReference` \$1 `attributionPeriod`
### Detalhes do parâmetro
ID do membro (opcional)
O identificador do membro a ser adicionado ao Grupo.
Tipo: Identificador
Sistema: Sistema de identificação de pacientes
```
{
"name": "memberId",
"valueIdentifier": {
"system": "http://example.org/patient-id",
"value": "patient-new"
}
}
```
ProviderNPI (opcional)
O Identificador Nacional do Provedor (NPI) do provedor atribuído.
Tipo: Identificador
Sistema: http://terminology.hl7. org/CodeSystem/NPI
```
{
"name": "providerNpi",
"valueIdentifier": {
"system": "http://terminology.hl7.org/CodeSystem/NPI",
"value": "1234567890"
}
}
```
Referência do paciente (opcional)
Referência direta ao recurso do paciente a ser adicionado.
Tipo: Referência
```
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/patient-123"
}
}
```
Referência do provedor (opcional)
Referência direta ao recurso do provedor.
Tipo: Referência
```
{
"name": "providerReference",
"valueReference": {
"reference": "Practitioner/provider-456"
}
}
```
Período de atribuição (opcional)
O período de tempo durante o qual o paciente é atribuído ao provedor.
Tipo: Período
```
{
"name": "attributionPeriod",
"valuePeriod": {
"start": "2024-07-15",
"end": "2025-07-14"
}
}
```
## Exemplos de solicitações
### Usando ID de membro e NPI do provedor
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "memberId",
"valueIdentifier": {
"system": "http://example.org/patient-id",
"value": "patient-new"
}
},
{
"name": "providerNpi",
"valueIdentifier": {
"system": "http://terminology.hl7.org/CodeSystem/NPI",
"value": "1234567890"
}
},
{
"name": "attributionPeriod",
"valuePeriod": {
"start": "2024-07-15",
"end": "2025-07-14"
}
}
]
}
```
### Usando referências de pacientes e provedores
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/patient-123"
}
},
{
"name": "providerReference",
"valueReference": {
"reference": "Practitioner/provider-456"
}
},
{
"name": "attributionPeriod",
"valuePeriod": {
"start": "2024-07-15",
"end": "2025-07-14"
}
}
]
}
```
## Formato de resposta
### Resposta de adição bem-sucedida
```
HTTP Status: 200 OK
Content-Type: application/fhir+json
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "success",
"code": "informational",
"details": {
"text": "Member Patient/patient-new successfully added to the Member Attribution List."
}
}
]
}
```
### Respostas de erro
Sintaxe de solicitação inválida
Status HTTP: 400 Solicitação inválida
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "invalid",
"details": {
"text": "Invalid parameter combination provided"
}
}
]
}
```
Recurso não encontrado
Status HTTP: 404 não encontrado
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-found",
"details": {
"text": "Resource not found."
}
}
]
}
```
Conflito de versão
Status HTTP: 409 Conflito
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "conflict",
"details": {
"text": "Resource version conflict detected"
}
}
]
}
```
Status de atribuição inválido
Status HTTP: 422 Entidade não processável
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "business-rule",
"details": {
"text": "Cannot add member to Attribution List with status 'final'. Status must be 'draft' or 'open'."
}
}
]
}
```
## Regras de negócios
Validação do status de atribuição
A operação só pode ser realizada quando o Status de Atribuição do Grupo é:
+ `draft`
+ `open`
As operações não são permitidas quando o status é`final`.
Prevenção de membros duplicados
O sistema evita a adição de membros duplicados com base na combinação exclusiva de:
+ Identificador de membro
+ Identificador do pagador
+ Identificador de cobertura
Validação do período de cobertura
Quando um `attributionPeriod` é fornecido, ele deve estar dentro dos limites do período de cobertura do membro. O sistema vai:
+ Pesquise o recurso de cobertura do membro
+ Use a cobertura mais recente (versionID mais alta) se existirem várias
+ Valide que o período de atribuição não exceda o período de cobertura
Validação de referência
Quando a ID e a referência são fornecidas para o mesmo recurso (paciente ou profissional), o sistema valida que elas correspondem ao mesmo recurso.
Quando os campos ID e reference.identifier são fornecidos para o mesmo recurso (paciente ou provedor), ocorre um erro.
## Autenticação e autorização
A operação requer autorização SMART on FHIR para:
+ Permissões de leitura - Para validar recursos de pacientes, provedores e grupos
+ Permissões de pesquisa - Para encontrar recursos por identificador
+ Atualizar permissões - Para modificar o recurso do Grupo
## Comportamento operacional
Atualizações de recursos
+ Atualiza o ID da versão do recurso do grupo
+ Cria uma entrada de histórico com o estado original do recurso antes da operação
+ Adiciona informações do membro à matriz group.Member com:
+ Referência do paciente em entity.reference
+ Período de atribuição em período
+ Cobertura e informações do provedor em campos de extensão
Passos de validação
+ Validação de parâmetros - Garante combinações de parâmetros válidas
+ Existência de recursos - Valida a existência de recursos para pacientes, provedores e grupos
+ Status de atribuição - Confirma que o status do grupo permite modificações
+ Verificação duplicada - Impede a adição de membros existentes
+ Validação da cobertura - Garante que o período de atribuição esteja dentro dos limites da cobertura
## Limitações
+ Todos os recursos referenciados devem existir no mesmo armazenamento de dados
+ A operação só funciona com recursos do Grupo de Lista de Atribuição de Membros
+ Os períodos de atribuição devem estar dentro dos limites de cobertura
+ Não é possível modificar grupos com status “final”
# `$member-match`operação para HealthLake
AWS HealthLake agora oferece suporte à `$member-match` operação de recursos para pacientes, permitindo que as organizações de saúde encontrem o identificador exclusivo de um membro em diferentes sistemas de saúde usando informações demográficas e de cobertura. Essa operação é essencial para alcançar a conformidade com o CMS e facilitar a troca segura de payer-to-payer dados, mantendo a privacidade do paciente.
Essa operação é particularmente útil quando você precisa:
+ Permita a troca segura de dados de saúde entre organizações
+ Mantenha a continuidade do atendimento ao paciente em diferentes sistemas
+ Support os requisitos de conformidade do CMS
+ Facilite a identificação precisa dos membros em todas as redes de saúde
## Usage
A `$member-match` operação pode ser invocada nos recursos do paciente usando o método POST:
```
POST [base]/Patient/$member-match
```
## Parâmetros compatíveis
HealthLake suporta os seguintes parâmetros FHIR: `$member-match`
| Parâmetro | Tipo | Obrigatório | Padrão | Description |
| --- | --- | --- | --- | --- |
| MemberPatient | Paciente | Sim | — | Recurso para pacientes contendo informações demográficas para o membro a ser combinado |
| CoverageToMatch | Cobertura | Sim | — | Recurso de cobertura que será usado para comparar com os registros existentes |
| CoverageToLink | Cobertura | Não | — | Recurso de cobertura a ser vinculado durante o processo de correspondência |
| Consentimento | Consentimento | Não | — | Recurso de consentimento para fins de autorização |
## Exemplos
### Solicitação POST com parâmetros
```
POST [base]/Patient/$member-match
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "MemberPatient",
"resource": {
"resourceType": "Patient",
"name": [
{
"family": "Jones",
"given": ["Sarah"]
}
],
"gender": "female",
"birthDate": "1985-05-15"
}
},
{
"name": "CoverageToMatch",
"resource": {
"resourceType": "Coverage",
"status": "active",
"beneficiary": {
"reference": "Patient/1"
},
"relationship": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code": "self",
"display": "Self"
}
]
},
"payor": [
{
"reference": "Organization/payer456"
}
]
}
},
{
"name": "Consent",
"resource": {
"resourceType": "Consent",
"status": "active",
"scope": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/consentscope",
"code": "patient-privacy"
}
]
},
"category": [
{
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
"code": "IDSCL"
}
]
}
],
"patient": {
"reference": "Patient/1"
},
"performer": [
{
"reference": "Patient/patient123"
}
],
"sourceReference": {
"reference": "Document/someconsent"
},
"policy": [
{
"uri": "http://hl7.org/fhir/us/davinci-hrex/StructureDefinition-hrex-consent.html#regular"
}
]
}
}
]
}
```
### Resposta da amostra
A operação retorna um recurso de Parâmetros contendo os resultados correspondentes:
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "MemberIdentifier",
"valueIdentifier": {
"system": "http://hospital.org/medical-record-number",
"value": "MRN-123456"
}
},
{
"name": "MemberId",
"valueReference": {
"reference": "Patient/patient123"
}
},
{
"name": "matchAlgorithm",
"valueString": "DEMOGRAPHIC_MATCH"
},
{
"name": "matchDetails",
"valueString": "Demographic match: DOB + Name"
},
{
"name": "matchedFields",
"valueString": "given,birthdate,gender,family"
}
]
}
```
## Parâmetros de resposta
A resposta inclui os seguintes parâmetros quando uma correspondência é encontrada:
| Parâmetro | Tipo | Description |
| --- | --- | --- |
| MemberIdentifier | Identificador | O identificador exclusivo do membro correspondente |
| MemberId | Referência | Referência ao recurso do paciente |
| algoritmo de correspondência | String | Tipo de algoritmo de correspondência usado (EXACT\$1MATCH, STRONG\$1MATCH ou DEMOGRAPHIC\$1MATCH) |
| Detalhes da partida | String | Informações detalhadas sobre o processo de correspondência |
| Campos correspondentes | String | Lista de campos específicos que foram combinados com sucesso |
## Algoritmos correspondentes
A `$member-match` API emprega uma abordagem de correspondência em vários níveis para garantir a identificação precisa dos membros:
COINCIDÊNCIA EXATA
Usa o identificador do paciente combinado com a cobertura SubscriberId
Fornece o mais alto nível de confiança para correspondência de membros
STRONG\$1MATCH
Usa o Patient Identifier com informações mínimas de cobertura
Oferece alta confiança quando os critérios de correspondência exata não são atendidos
CORRESPONDÊNCIA DEMOGRÁFICA
Baseia-se em informações demográficas básicas
Usado quando a correspondência baseada em identificador não é possível
## Comportamento
A `$member-match` operação:
+ Aceita dados demográficos do paciente, detalhes da cobertura e informações de consentimento opcionais como entrada
+ Retorna um identificador de membro exclusivo que pode ser usado para interações subsequentes
+ Implementa a correspondência em vários níveis (exata, forte, demográfica) para garantir a identificação precisa dos membros em diferentes sistemas de saúde
+ Salva todas as informações de consentimento fornecidas para fins de autorização futura
+ Oferece suporte à troca segura de payer-to-payer dados enquanto mantém a privacidade do paciente
+ Cumpre os requisitos do CMS para troca de dados de saúde
## Autorização
A API usa SMART no protocolo de autorização FHIR com os seguintes escopos obrigatórios:
+ `system/Patient.read`
+ `system/Coverage.read`
+ `system/Organization.read`(condicional)
+ `system/Practitioner.read`(condicional)
+ `system/PractitionerRole.read`(condicional)
+ `system/Consent.write`(condicional)
## Tratamento de erros
A operação trata das seguintes condições de erro:
+ `400 Bad Request`: `$member-match` operação inválida (solicitação não conforme ou ausência de parâmetros obrigatórios)
+ `422 Unprocessable Entity`: Nenhuma correspondência ou várias correspondências encontradas
# `$member-remove`operação para HealthLake
A `$member-remove` operação permite que você remova membros de uma Lista de Atribuição de Membros do FHIR (recurso de grupo) em. AWS HealthLake Essa operação faz parte do Guia de Implementação de Atribuição de DaVinci Membros e apoia o processo de reconciliação para gerenciar as atribuições de membros.
## Pré-requisitos
+ AWS HealthLake Armazenamento de dados FHIR
+ Permissões apropriadas do IAM para HealthLake operações
+ Lista de atribuição de membros (recurso do grupo) em status de rascunho ou aberto
## Detalhes da operação
Endpoint
`POST /Group/{id}/$member-remove`
Tipo de conteúdo
`application/fhir+json`
## Parâmetros
A operação aceita um recurso de parâmetros FHIR com os seguintes parâmetros opcionais:
| Parâmetro | Cardinalidade | Tipo | Description |
| --- | --- | --- | --- |
| memberId | 0,1 | Identificador | Identificador comercial do membro a ser removido |
| NPI do provedor | 0,1 | Identificador | NPI do provedor atribuído |
| Referência do paciente | 0,1 | Referência | Referência direta ao recurso do paciente |
| Referência do provedor | 0,1 | Referência | Referência direta ao recurso do provedor (profissional ou organização) PractitionerRole |
| Referência de cobertura | 0,1 | Referência | Referência ao recurso de cobertura |
### Combinações de parâmetros suportadas
As seguintes combinações de parâmetros são suportadas:
+ `memberId`somente - Remove todas as atribuições do membro especificado
+ `memberId`\$1 `providerNpi` - Remove as atribuições da combinação específica de membro-provedor
+ `patientReference`somente - Remove todas as atribuições do paciente especificado
+ `patientReference`\$1 `providerReference` - Remove as atribuições da combinação específica paciente-provedor
+ `patientReference`\$1 `providerReference` \$1 `coverageReference` - Remove a atribuição específica com base no paciente, no provedor e na cobertura
## Exemplo de solicitação
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/12345"
}
},
{
"name": "providerReference",
"valueReference": {
"reference": "Practitioner/67890"
}
}
]
}
```
## Resposta
### Resposta bem-sucedida
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "result",
"valueBoolean": true
},
{
"name": "effectiveDate",
"valueDate": "2024-06-30"
},
{
"name": "status",
"valueCode": "inactive"
},
{
"name": "message",
"valueString": "Member successfully removed from attribution list"
}
]
}
```
## Comportamento
Requisitos de status
A operação só funciona em listas de atribuição com status ou `draft` `open`
Listas com `final` status rejeitarão a operação com um erro 422
Processo de remoção de membros
*Listas de status preliminares*: os membros são marcados como inativos (`inactive: true`) e sua `changeType` extensão é atualizada para `changed`
*Listas de status abertas*: comportamento semelhante ao status de rascunho
*Listas de status finais*: A operação foi rejeitada
Validação
As referências são validadas para garantir que existam no armazenamento de dados HealthLake
Se o identificador e a referência forem fornecidos para o mesmo tipo de recurso, eles deverão corresponder ao mesmo recurso
As combinações de parâmetros são validadas de acordo com os padrões suportados
## Tratamento de erros
### Respostas de erro comuns
Recurso não encontrado (404)
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-found",
"details": {
"text": "Patient with identifier 'http://example.org/fhir/identifiers|99999' not found in system"
},
"diagnostics": "Cannot remove member from attribution list. Verify patient identifier and try again.",
"expression": ["memberId"]
}
]
}
```
Status final da lista de atribuições (422)
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "business-rule",
"details": {
"coding": [
{
"system": "http://hl7.org/fhir/us/davinci-atr/CodeSystem/atr-error-codes",
"code": "list-final",
"display": "Attribution list is final and cannot be modified"
}
]
},
"diagnostics": "Cannot modify attribution list with status 'final'. List modifications are not permitted after finalization.",
"expression": ["Group.status"]
}
]
}
```
Operação inválida (400)
Retornado quando as combinações de parâmetros são inválidas ou malformadas.
Várias correspondências encontradas (412)
Retornado quando os parâmetros fornecidos correspondem a vários membros na lista de atribuição.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "processing",
"diagnostics": "Multiple members found matching the criteria"
}
]
}
```
## Práticas recomendadas
+ *Use parâmetros específicos*: quando possível, use a combinação de parâmetros mais específica para evitar remoções não intencionais
+ *Status da lista de verificação*: verifique o status da lista de atribuição antes de tentar remoções
+ *Lide com erros normalmente: implemente* o tratamento adequado de erros para todas as condições de erro possíveis
+ *Validar referências*: certifique-se de que todos os recursos referenciados existam antes de fazer a solicitação
# Removendo recursos do compartimento do paciente com `$purge`
AWS HealthLake suporta a `$purge` operação, permitindo a exclusão permanente de todos os recursos dentro do compartimento do paciente. Essa operação é particularmente útil quando você precisa:
+ Remova todos os dados associados a um paciente
+ Cumpra as solicitações de remoção de dados do paciente
+ Gerencie o ciclo de vida dos dados do paciente
+ Execute uma limpeza abrangente do prontuário do paciente
## Usage
A `$purge` operação pode ser invocada nos recursos do paciente:
```
POST [base]/Patient/[ID]/$purge?deleteAuditEvent=true
```
## Parâmetros
| Parâmetro | Tipo | Obrigatório | Padrão | Description |
| --- | --- | --- | --- | --- |
| deleteAuditEvent | booliano | Não | false | Quando verdadeiro, exclui os eventos de auditoria associados |
| \$1since | string | Não | Horário de criação do armazenamento de dados | Quando inserido, seleciona a hora limite inicial para encontrar recursos com base na hora da Última Modificação. Não pode ser usado com início ou fim |
| start | string | Não | Horário de criação do armazenamento de dados | Quando inserido, seleciona o horário limite para encontrar recursos com base no horário da Última Modificação. Pode ser usado com extremidade |
| end | string | Não | Horário de envio do trabalho | Quando inserido, seleciona a hora limite final para encontrar recursos com base na hora da Última Modificação |
## Exemplos
**Exemplo de solicitação**
```
POST [base]/Patient/example-patient/$purge?deleteAuditEvent=true
```
**Exemplo de resposta**
```
{
"resourceType": "OperationOutcome",
"id": "purge-job",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Purge job started successfully. Job ID: 12345678-1234-1234-1234-123456789012"
}
]
}
```
## Status do trabalho
Para verificar o status de uma tarefa de expurgação:
```
GET [base]/$purge/[jobId]
```
A operação retorna informações sobre o status do trabalho:
```
{
"datastoreId": "36622996b1fcecb7e12ee2ee085308d3",
"jobId": "3dd1c7a5b6c0ef8c110f566eb87e2ef9",
"status": "COMPLETED",
"submittedTime": "2025-10-31T18:43:21.822Z"
}
```
## Comportamento
A `$purge` operação:
1. Processa de forma assíncrona para lidar com vários recursos
1. Mantém as transações ACID para a integridade dos dados
1. Fornece rastreamento do status do trabalho com contagens de exclusões de recursos
1. Remove permanentemente todos os recursos no compartimento do paciente
1. Inclui registro abrangente de auditoria das atividades de exclusão
1. Oferece suporte à exclusão seletiva de eventos de auditoria
## Registro de auditoria
A `$purge` operação é registrada como Iniciar FHIRBulk DeleteJob e Descrever FHIRBulk DeleteJob com informações detalhadas da operação.
## Limitações
+ Os recursos eliminados não aparecerão nas respostas de pesquisa
+ Os recursos que estão sendo eliminados podem ficar temporariamente inacessíveis durante o processamento
+ Todos os recursos no compartimento do paciente são removidos permanentemente
# Operação FHIR para `$questionnaire-package` HealthLake
A `$questionnaire-package` operação recupera um pacote abrangente contendo um questionário FHIR e todas as dependências necessárias para renderizar e processar o questionário. Essa operação implementa o [Guia de Implementação de Modelos e Regras de Documentação Da Vinci (DTR)](https://hl7.org/fhir/us/davinci-dtr/OperationDefinition-questionnaire-package.html), permitindo a renderização dinâmica de formulários para requisitos de documentação em fluxos de trabalho de saúde.
## Como funciona
+ **Solicitação**: você envia parâmetros identificando o (s) questionário (s) necessário (s), juntamente com a cobertura e o contexto do pedido
+ **Recuperar**: HealthLake reúne o questionário e todas as dependências (bibliotecas CQLValueSets, etc.)
+ **Package**: Todos os recursos são agrupados em um formato padronizado
+ **Responder**: Você recebe um pacote completo pronto para renderização e coleta de dados
**Casos de uso**
+ **Documentação de autorização prévia**: colete as informações clínicas necessárias para solicitações de autorização prévia
+ **Requisitos de cobertura**: reúna a documentação necessária para satisfazer os requisitos de cobertura do pagador
+ **Clinical Data Exchange**: Estruture os dados clínicos para envio aos pagadores
+ **Formulários dinâmicos**: renderize questionários com dados pré-preenchidos do paciente e lógica condicional
## Ponto final da API
```
POST /datastore/{datastoreId}/r4/Questionnaire/$questionnaire-package
Content-Type: application/fhir+json
```
## Parâmetros de solicitação
### Parâmetros de entrada
O corpo da solicitação deve conter um recurso de parâmetros FHIR com os seguintes parâmetros:
| Parâmetro | Tipo | Cardinalidade | Description |
| --- | --- | --- | --- |
| coverage | Cobertura | 1.. \$1 (Obrigatório) | Recurso (s) de cobertura para estabelecer o membro e cobertura para documentação |
| questionnaire | canônico | 0.. \$1 | URL (s) canônica (s) para que questionários específicos retornem (podem incluir a versão) |
| order | Recurso | 0.. \$1 | Solicite recursos (DeviceRequest,, ServiceRequest MedicationRequest, Encontro, Nomeação) para estabelecer o contexto |
| changedSince | dateTime | 0,1 | Se estiver presente, retorne somente os recursos alterados após esse registro de data e hora |
### Regras de validação de parâmetros
**Pelo menos UM dos seguintes itens deve ser fornecido** (além do obrigatório`coverage`):
+ Um ou mais `questionnaire` canônicos URLs
+ Um ou mais `order` recursos
**Combinações de solicitações válidas:**
+ `coverage` \$1 `questionnaire`
+ `coverage` \$1 `order`
+ `coverage` \$1 `questionnaire` \$1 `order`
## Exemplo de solicitação
```
POST /datastore/example-datastore/r4/Questionnaire/$questionnaire-package
Content-Type: application/fhir+json
Authorization: Bearer
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": {
"resourceType": "Coverage",
"id": "example-coverage",
"status": "active",
"beneficiary": {
"reference": "Patient/example-patient"
},
"payor": [{
"reference": "Organization/example-payer"
}],
"class": [{
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/coverage-class",
"code": "group"
}]
},
"value": "12345"
}]
}
},
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/home-oxygen-therapy|2.0"
},
{
"name": "order",
"resource": {
"resourceType": "ServiceRequest",
"id": "example-service-request",
"status": "active",
"intent": "order",
"code": {
"coding": [{
"system": "http://www.ama-assn.org/go/cpt",
"code": "94660",
"display": "Continuous positive airway pressure ventilation (CPAP)"
}]
},
"subject": {
"reference": "Patient/example-patient"
}
}
},
{
"name": "changedSince",
"valueDateTime": "2024-01-01T00:00:00Z"
}
]
}
```
## Formato de resposta
### Resposta de sucesso (200 OK)
A operação retorna um recurso FHIR Parameters contendo um ou mais **Package** Bundles. Cada pacote Package inclui:
| Tipo de entrada | Cardinalidade | Description |
| --- | --- | --- |
| Questionário | 1 | O questionário a ser entregue |
| QuestionnaireResponse | 0,1 | Resposta pré-preenchida ou parcialmente preenchida (se aplicável) |
| Ferramentas | 0.. \$1 | Bibliotecas CQL contendo pré-população e lógica condicional |
| ValueSet | 0.. \$1 | Expandido ValueSets (para opções de resposta com menos de 40 expansões) |
**Example Exemplo de resposta**
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "PackageBundle",
"resource": {
"resourceType": "Bundle",
"id": "questionnaire-package-example",
"meta": {
"profile": ["http://hl7.org/fhir/us/davinci-dtr/StructureDefinition/DTR-QPackageBundle"]
},
"type": "collection",
"timestamp": "2024-03-15T10:30:00Z",
"entry": [
{
"fullUrl": "http://example.org/fhir/Questionnaire/home-oxygen-therapy",
"resource": {
"resourceType": "Questionnaire",
"id": "home-oxygen-therapy",
"url": "http://example.org/fhir/Questionnaire/home-oxygen-therapy",
"version": "2.0",
"status": "active",
"title": "Home Oxygen Therapy Documentation",
"item": [
{
"linkId": "1",
"text": "Patient diagnosis",
"type": "choice",
"answerValueSet": "http://example.org/fhir/ValueSet/oxygen-diagnoses"
}
]
}
},
{
"fullUrl": "http://example.org/fhir/Library/oxygen-prepopulation",
"resource": {
"resourceType": "Library",
"id": "oxygen-prepopulation",
"url": "http://example.org/fhir/Library/oxygen-prepopulation",
"version": "1.0",
"type": {
"coding": [{
"system": "http://terminology.hl7.org/CodeSystem/library-type",
"code": "logic-library"
}]
},
"content": [{
"contentType": "text/cql",
"data": "bGlicmFyeSBPeHlnZW5QcmVwb3B1bGF0aW9u..."
}]
}
},
{
"fullUrl": "http://example.org/fhir/ValueSet/oxygen-diagnoses",
"resource": {
"resourceType": "ValueSet",
"id": "oxygen-diagnoses",
"url": "http://example.org/fhir/ValueSet/oxygen-diagnoses",
"status": "active",
"expansion": {
"timestamp": "2024-03-15T10:30:00Z",
"contains": [
{
"system": "http://hl7.org/fhir/sid/icd-10",
"code": "J44.0",
"display": "COPD with acute lower respiratory infection"
},
{
"system": "http://hl7.org/fhir/sid/icd-10",
"code": "J96.01",
"display": "Acute respiratory failure with hypoxia"
}
]
}
}
},
{
"fullUrl": "http://example.org/fhir/QuestionnaireResponse/example-prepopulated",
"resource": {
"resourceType": "QuestionnaireResponse",
"id": "example-prepopulated",
"questionnaire": "http://example.org/fhir/Questionnaire/home-oxygen-therapy|2.0",
"status": "in-progress",
"subject": {
"reference": "Patient/example-patient"
},
"basedOn": [{
"reference": "ServiceRequest/example-service-request"
}],
"item": [
{
"linkId": "1",
"text": "Patient diagnosis",
"answer": [{
"valueCoding": {
"system": "http://hl7.org/fhir/sid/icd-10",
"code": "J44.0",
"display": "COPD with acute lower respiratory infection"
}
}]
}
]
}
}
]
}
},
{
"name": "Outcome",
"resource": {
"resourceType": "OperationOutcome",
"issue": [{
"severity": "information",
"code": "informational",
"details": {
"text": "Successfully retrieved questionnaire package"
}
}]
}
}
]
}
```
## Fluxo de trabalho operacional
**Como HealthLake processa sua solicitação**
Quando você liga`$questionnaire-package`, HealthLake executa as seguintes etapas:
1. **Identifique o paciente e o pagador**: extrai o paciente e a organização de seguros do seu `coverage` parâmetro.
1. **Encontre o questionário certo**:
+ **Com `questionnaire`** **parâmetro**: usa o URL canônico que você forneceu
+ **Com `order`** **parâmetro**: combina o código do pedido (CPT/HCPCS/LOINC) e o pagador para encontrar o questionário apropriado
1. **Coletar dependências**: recupera automaticamente tudo o que é necessário para renderizar o questionário:
+ **Bibliotecas CQL** - Lógica para questões pré-populacionais e condicionais
+ **ValueSets**- Opções de resposta (expandidas automaticamente se <40 opções)
+ **QuestionnaireResponse**- Qualquer resposta existente em andamento ou concluída
1. **Package tudo junto**:
+ Agrupa todos os recursos (cada recurso incluído apenas uma vez)
+ Filtra por `changedSince` data e hora, se fornecido
+ Adiciona avisos `Outcome` se algum recurso estiver faltando
**Resultado**: um pacote completo e independente pronto para renderização.
## Respostas de erro
### 400 solicitação inválida
Retornado quando a validação da solicitação falha.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "required",
"details": {
"text": "At least one of 'questionnaire' or 'order' must be provided along with 'coverage'"
}
}]
}
```
### 424 Dependência falhada
Retornado quando um recurso dependente não pode ser recuperado.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "warning",
"code": "not-found",
"details": {
"text": "Referenced Library 'http://example.org/fhir/Library/missing-library' could not be retrieved"
}
}]
}
```
### 401 Não autorizado
Retornado quando as credenciais de autenticação estão ausentes ou são inválidas.
### 403 proibido
Retornado quando o usuário autenticado não tem permissão para acessar os recursos solicitados.
### 406 Não aceitável
Retornado quando o tipo de conteúdo solicitado não pode ser fornecido.
### 409 Conflito
Retornado quando há um conflito de versão ou simultaneidade.
### 410 Desaparecido
Retornado quando o recurso solicitado foi excluído permanentemente.
### 429, muitas solicitações
Retornado quando os limites de taxa são excedidos.
### 500 Internal Server Error
Retornado quando ocorre um erro inesperado no servidor.
### 501 Não implementado
Retornado quando a operação solicitada ainda não foi implementada.
## Regras de validação
### Validação de entrada
+ `coverage`parâmetro é **obrigatório** (1.. \$1 cardinalidade)
+ Pelo menos um dos `questionnaire` ou `order` deve ser fornecido
+ Todos os recursos de cobertura devem ser recursos FHIR válidos
+ Todos os recursos do Pedido devem ser recursos FHIR válidos
+ O canônico URLs deve ser formatado corretamente
+ `changedSince`deve ser um ISO 8601 DateTime válido
### QuestionnaireResponse validação
+ `status`deve ser apropriado (`in-progress`,`completed`,`amended`)
+ A estrutura deve corresponder ao questionário referenciado
+ `basedOn`deve fazer referência a recursos válidos do Pedido
+ `subject`deve referenciar recursos válidos para pacientes
### Desduplicação de recursos
+ Cada recurso aparece somente uma vez no pacote
+ Exceção: versões diferentes do mesmo recurso podem ser incluídas
+ Os recursos são identificados por seu URL e versão canônicos
## Especificações de performance
| Métrica | Especificação |
| --- | --- |
| Limite de contagem de recursos | 500 recursos por pacote |
| Limite de tamanho do pacote | Máximo de 5 MB |
## Permissões obrigatórias
Para usar a `$questionnaire-package` operação, certifique-se de que sua função do IAM tenha:
+ `healthlake:QuestionnairePackage`- Para chamar a operação
+ `healthlake:ReadResource`- Para recuperar o questionário e os recursos dependentes
+ `healthlake:SearchWithPost`- Para pesquisar QuestionnaireResponse e recursos relacionados
**SMART em escopos FHIR**
**Escopos mínimos exigidos:**
+ **SMART v1:** `user/Questionnaire.read user/Library.read user/ValueSet.read user/QuestionnaireResponse.read`
+ **SMART v2:** `user/Questionnaire.rs user/Library.rs user/ValueSet.rs user/QuestionnaireResponse.rs`
## Notas de implementação importantes
### Estratégia de recuperação de recursos
**Prioridade de identificação do questionário:**
+ **URL canônica** (se o `questionnaire` parâmetro for fornecido) - Prioridade mais alta
+ **Análise do pedido** (se o `order` parâmetro for fornecido):
+ Combine os códigos de pedido (CPT, HCPCS, LOINC) com as políticas médicas do pagador
+ Use o pagador de cobertura para filtrar questionários específicos do pagador
+ Considere os códigos de motivo para um contexto adicional
### Resolução de dependências
**Bibliotecas CQL:**
+ Recuperado por meio da `cqf-library` extensão nos recursos do questionário
+ Busca recursivamente bibliotecas dependentes por meio de tipo `Library.relatedArtifact` `depends-on`
+ Todas as dependências da biblioteca estão incluídas no pacote
**ValueSets:**
+ Expandido automaticamente se eles contiverem menos de 40 conceitos
+ Maiores ValueSets estão incluídos sem expansão
+ ValueSets referenciados no questionário e nos recursos da biblioteca estão incluídos
### QuestionnaireResponse pré-população
A operação pode retornar um QuestionnaireResponse com dados pré-preenchidos quando:
+ Uma resposta existente em andamento ou concluída foi encontrada
+ A lógica CQL nas bibliotecas associadas pode extrair dados dos registros dos pacientes
+ A resposta está vinculada ao pedido e à cobertura relevantes
**Critérios de pesquisa para QuestionnaireResponse:**
| Parâmetro de pesquisa | Caminho FHIR | Description |
| --- | --- | --- |
| based-on | QuestionnaireResponse.basedOn | Links para ServiceRequest ou CarePlan |
| patient | QuestionnaireResponse.subject | O paciente que é o sujeito |
| questionnaire | QuestionnaireResponse.questionnaire | O questionário que está sendo respondido |
### Filtragem de recursos alterada
Quando o `changedSince` parâmetro é fornecido:
+ Somente os recursos modificados **após** o registro de data e hora especificado são incluídos
+ Se nenhum recurso tiver sido alterado, retorna `200 OK` com um pacote vazio
+ Útil para atualizações incrementais e estratégias de armazenamento em cache
+ A comparação de timestamp usa o campo de recurso `meta.lastUpdated`
### Vários pacotes
A operação pode retornar **vários Package Bundles** quando:
+ Vários questionários são solicitados via canonical URLs
+ Vários pedidos exigem questionários diferentes
+ Versões diferentes do mesmo questionário são aplicáveis
Cada Package Bundle é independente com todas as dependências necessárias.
## Casos de uso comuns
### Caso de uso 1: documentação de autorização prévia
**Cenário**: Um provedor precisa coletar a documentação para uma autorização prévia de oxigenoterapia domiciliar.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Patient's insurance coverage */ }
},
{
"name": "order",
"resource": {
"resourceType": "ServiceRequest",
"code": {
"coding": [{
"system": "http://www.ama-assn.org/go/cpt",
"code": "94660"
}]
}
}
}
]
}
```
**Resultado**: Retorna um pacote com o questionário de oxigenoterapia, pré-preenchido com os sinais vitais do paciente e os códigos de diagnóstico do EHR.
### Caso de uso 2: Recuperar a versão específica do questionário
**Cenário**: um provedor precisa de uma versão específica de um questionário para fins de conformidade.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Coverage resource */ }
},
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/dme-request|3.1.0"
}
]
}
```
**Resultado**: retorna exatamente a versão 3.1.0 do questionário de solicitação do DME com todas as dependências.
### Caso de uso 3: verifique se há atualizações
**Cenário**: um provedor deseja verificar se algum recurso do questionário foi atualizado desde a última recuperação.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Coverage resource */ }
},
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/medication-request"
},
{
"name": "changedSince",
"valueDateTime": "2024-03-01T00:00:00Z"
}
]
}
```
**Resultado**: retorna somente recursos que foram modificados após 1º de março de 2024 ou um pacote vazio se nada tiver sido alterado.
### Caso de uso 4: vários pedidos
**Cenário**: um provedor envia várias solicitações de serviço que podem exigir questionários diferentes.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Coverage resource */ }
},
{
"name": "order",
"resource": { /* ServiceRequest for imaging */ }
},
{
"name": "order",
"resource": { /* ServiceRequest for DME */ }
}
]
}
```
**Resultado**: retorna vários Package Bundles, um para cada questionário aplicável.
## Integração com outros Da Vinci IGs
### Descoberta de requisitos de cobertura (CRD)
**Integração do fluxo de trabalho:**
+ O provedor solicita um serviço em seu EHR
+ O gancho do CRD dispara, verificando os requisitos de cobertura
+ O pagador responde indicando que a documentação é necessária
+ O provedor liga `$questionnaire-package` para recuperar o formulário de documentação
+ O provedor preenche o questionário
+ A documentação é enviada via PAS ou CDex
### Suporte de autorização prévia (PAS)
**Integração do fluxo de trabalho:**
+ Use `$questionnaire-package` para recuperar os requisitos de documentação
+ Preencha o QuestionnaireResponse com os dados clínicos necessários
+ Envie a autorização prévia usando `Claim/$submit` com o preenchido QuestionnaireResponse
+ Verifique o status usando `Claim/$inquire`
### Troca de dados clínicos (CDex)
**Integração do fluxo de trabalho:**
+ O pagador solicita documentação adicional para uma reclamação
+ O provedor usa `$questionnaire-package` para recuperar o formulário estruturado de coleta de dados
+ O provedor conclui o QuestionnaireResponse
+ A documentação é enviada ao pagador por meio do fluxo de trabalho de CDex anexos
## Guia de solução de problemas
### Problema: Nenhum questionário foi devolvido
**Causas possíveis:**
+ O URL canônico não corresponde a nenhum questionário no armazenamento de dados
+ O código do pedido não é mapeado para nenhum questionário na política médica do pagador
+ O pagador da cobertura não tem questionários associados
**Soluções:**
+ Verifique se o URL canônico está correto e se o questionário existe
+ Verifique se os códigos de pedido (CPT/HCPCS) estão especificados corretamente
+ Confirme se a organização pagadora tem questionários configurados
### Problema: dependências ausentes no Package
**Causas possíveis:**
+ Biblioteca referenciada ou ValueSet não existe no armazenamento de dados
+ As referências da biblioteca estão quebradas ou incorretas
+ ValueSet a expansão falhou
**Soluções:**
+ Verifique o `Outcome` parâmetro para ver se há avisos sobre recursos ausentes
+ Verifique se todos os recursos referenciados existem em seu armazenamento de dados
+ Certifique-se de que ValueSet URLs estão corretos e solucionáveis
### Problema: Empty Package com ChangedSince
**Causas possíveis:**
+ Esse é o comportamento esperado - nenhum recurso foi modificado desde o timestamp especificado
**Soluções:**
+ Use a versão em cache do pacote
+ Remova o `changedSince` parâmetro para recuperar o pacote completo
### Problema: QuestionnaireResponse Não pré-preenchido
**Causas possíveis:**
+ Não foi QuestionnaireResponse encontrado nenhum existente
+ A lógica da biblioteca CQL não conseguiu extrair os dados necessários
+ Os dados do paciente estão ausentes ou incompletos
**Soluções:**
+ Isso pode ser esperado - nem todos os questionários têm lógica pré-populacional
+ Verifique se os dados do paciente existem no armazenamento de dados
+ Revise a lógica da Biblioteca CQL para requisitos de extração de dados
## Práticas recomendadas
### 1. Use Canonical com versões URLs
Sempre especifique os números das versões ao solicitar questionários específicos:
```
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/dme|2.1.0"
}
```
**Por quê**: Garante a consistência e evita alterações inesperadas quando os questionários são atualizados.
### 2. Aproveite o ChangedSince para desempenho
Para questionários acessados com frequência, use `changedSince` para minimizar a transferência de dados:
```
{
"name": "changedSince",
"valueDateTime": "2024-03-10T15:30:00Z"
}
```
**Por quê**: Reduz a latência e o uso da largura de banda recuperando somente recursos atualizados.
### 3. Inclua informações completas de cobertura
Forneça detalhes abrangentes da cobertura para garantir a seleção correta do questionário:
```
{
"name": "coverage",
"resource": {
"resourceType": "Coverage",
"beneficiary": { "reference": "Patient/123" },
"payor": [{ "reference": "Organization/payer-abc" }],
"class": [{ /* Group/plan information */ }]
}
}
```
**Por quê**: Ajuda a HealthLake identificar questionários e requisitos específicos do pagador.
## Operações do relacionadas
+ `Claim/$submit`- Envie solicitações de autorização prévia com a documentação completa
+ `Claim/$inquire`- Verifique o status das autorizações anteriores enviadas
+ `ValueSet/$expand`- Expandir ValueSets para opções de resposta
# Operação FHIR para `$submit` HealthLake
A `$submit` operação permite que você envie eletronicamente solicitações de autorização prévia aos pagadores para aprovação. Essa operação implementa o [Guia de Implementação do Da Vinci Prior Authorization Support (PAS)](https://hl7.org/fhir/us/davinci-pas/), fornecendo um fluxo de trabalho padronizado baseado em FHIR para envios de autorização prévia.
## Como funciona
+ **Enviar**: Você envia um pacote FHIR contendo sua solicitação de autorização prévia e dados clínicos de apoio
+ **Validar**: HealthLake valida o envio de acordo com os requisitos do PAS
+ **Persistir**: todos os recursos são armazenados em seu armazenamento HealthLake de dados
+ **Responder**: você recebe uma resposta imediata com o status “em fila”
+ **Processo**: A decisão de autorização é processada de forma assíncrona pelo pagador
## Ponto final da API
```
POST /datastore/{datastoreId}/r4/Claim/$submit
Content-Type: application/fhir+json
```
## Estrutura de solicitações
### Requisitos do pacote
Sua solicitação deve ser um recurso do FHIR Bundle com:
+ **Bundle.type**: Deve ser `"collection"`
+ **Bundle.entry**: deve conter exatamente **um** recurso de reivindicação com `use = "preauthorization"`
+ **Recursos referenciados**: todos os recursos referenciados pela reivindicação devem ser incluídos no pacote
### Recursos necessários
| Recurso | Cardinalidade | Perfil | Description |
| --- | --- | --- | --- |
| Reclamação | 1 | Reivindicação do PAS | A solicitação de autorização prévia |
| Paciente | 1 | Paciente PAS | Informações demográficas do paciente |
| Organização (Seguradora) | 1 | Seguradora PAS | Companhia de seguros |
| Organização (Provedor) | 1 | Solicitante do PAS | Provedor de serviços de saúde enviando a solicitação |
| Cobertura | 1 ou mais | Cobertura do PAS | Detalhes da cobertura do seguro |
### Recursos opcionais
| Recurso | Cardinalidade | Perfil | Description |
| --- | --- | --- | --- |
| Praticante | 0 ou mais | Praticante do PAS | Profissionais de saúde |
| PractitionerRole | 0 ou mais | PAS PractitionerRole | Funções do profissional |
| ServiceRequest | 0 ou mais | PAS ServiceRequest | Serviços médicos solicitados |
| DeviceRequest | 0 ou mais | PAS DeviceRequest | Dispositivos médicos solicitados |
| MedicationRequest | 0 ou mais | PAS MedicationRequest | Medicamentos solicitados |
| DocumentReference | 0 ou mais | PAS DocumentReference | Documentação clínica de apoio |
## Exemplo de solicitação
```
POST /datastore/example-datastore/r4/Claim/$submit
Content-Type: application/fhir+json
Authorization: Bearer
{
"resourceType" : "Bundle",
"id" : "MedicalServicesAuthorizationBundleExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-pas-request-bundle"]
},
"identifier" : {
"system" : "http://example.org/SUBMITTER_TRANSACTION_IDENTIFIER",
"value" : "5269367"
},
"type" : "collection",
"timestamp" : "2005-05-02T11:01:00+05:00",
"entry" : [{
"fullUrl" : "http://example.org/fhir/Claim/MedicalServicesAuthorizationExample",
"resource" : {
"resourceType" : "Claim",
"id" : "MedicalServicesAuthorizationExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim"]
},
"identifier" : [{
"system" : "http://example.org/PATIENT_EVENT_TRACE_NUMBER",
"value" : "111099"
}],
"status" : "active",
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/claim-type",
"code" : "professional"
}]
},
"use" : "preauthorization",
"patient" : {
"reference" : "Patient/SubscriberExample"
},
"created" : "2005-05-02T11:01:00+05:00",
"insurer" : {
"reference" : "Organization/InsurerExample"
},
"provider" : {
"reference" : "Organization/UMOExample"
},
"priority" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/processpriority",
"code" : "normal"
}]
},
"insurance" : [{
"sequence" : 1,
"focal" : true,
"coverage" : {
"reference" : "Coverage/InsuranceExample"
}
}],
"item" : [{
"extension" : [{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-serviceItemRequestType",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1525",
"code" : "IN",
"display" : "Initial Medical Services Reservation"
}]
}
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-certificationType",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1322",
"code" : "I",
"display" : "Initial"
}]
}
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-authorizationNumber",
"valueString" : "1122344"
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-administrationReferenceNumber",
"valueString" : "33441122"
}],
"sequence" : 1,
"category" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1365",
"code" : "1",
"display" : "Medical Care"
}]
},
"productOrService" : {
"coding" : [{
"system" : "http://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets",
"code" : "99212",
"display" : "Established Office Visit"
}]
},
"servicedDate" : "2005-05-10",
"locationCodeableConcept" : {
"coding" : [{
"system" : "https://www.cms.gov/Medicare/Coding/place-of-service-codes/Place_of_Service_Code_Set",
"code" : "11"
}]
}
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Organization/UMOExample",
"resource" : {
"resourceType" : "Organization",
"id" : "UMOExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor"]
},
"identifier" : [{
"system" : "http://hl7.org/fhir/sid/us-npi",
"value" : "8189991234"
}],
"active" : true,
"type" : [{
"coding" : [{
"system" : "https://codesystem.x12.org/005010/98",
"code" : "X3"
}]
}],
"name" : "DR. JOE SMITH CORPORATION",
"address" : [{
"line" : ["111 1ST STREET"],
"city" : "SAN DIEGO",
"state" : "CA",
"postalCode" : "92101",
"country" : "US"
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Organization/InsurerExample",
"resource" : {
"resourceType" : "Organization",
"id" : "InsurerExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer"]
},
"identifier" : [{
"system" : "http://hl7.org/fhir/sid/us-npi",
"value" : "1234567893"
}],
"active" : true,
"type" : [{
"coding" : [{
"system" : "https://codesystem.x12.org/005010/98",
"code" : "PR"
}]
}],
"name" : "MARYLAND CAPITAL INSURANCE COMPANY"
}
},
{
"fullUrl" : "http://example.org/fhir/Coverage/InsuranceExample",
"resource" : {
"resourceType" : "Coverage",
"id" : "InsuranceExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-coverage"]
},
"status" : "active",
"subscriberId" : "1122334455",
"beneficiary" : {
"reference" : "Patient/SubscriberExample"
},
"relationship" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code" : "self"
},
{
"system" : "https://codesystem.x12.org/005010/1069",
"code" : "18"
}]
},
"payor" : [{
"reference" : "Organization/InsurerExample"
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Patient/SubscriberExample",
"resource" : {
"resourceType" : "Patient",
"id" : "SubscriberExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-subscriber"]
},
"extension" : [{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-militaryStatus",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/584",
"code" : "RU"
}]
}
}],
"identifier" : [{
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
"code" : "MB"
}]
},
"system" : "http://example.org/MIN",
"value" : "12345678901"
}],
"name" : [{
"family" : "SMITH",
"given" : ["JOE"]
}],
"gender" : "male"
}
}]
}
```
## Formato de resposta
### Resposta de sucesso (200 OK)
Você receberá um pacote de respostas do PAS contendo:
+ **ClaimResponse**com `outcome: "queued"` e `status: "active"`
+ Todos os recursos originais de sua solicitação
+ Carimbo de data e hora confirmando o recebimento
```
{
"resourceType" : "Bundle",
"identifier": {
"system": "http://example.org/SUBMITTER_TRANSACTION_IDENTIFIER",
"value": "5269367"
},
"type" : "collection",
"timestamp" : "2005-05-02T11:02:00+05:00",
"entry" : [{
"fullUrl" : "http://example.org/fhir/ClaimResponse/PractitionerRequestorPendingResponseExample",
"resource" : {
"resourceType" : "ClaimResponse",
"id" : "PractitionerRequestorPendingResponseExample",
"meta" : {
"profile" : ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claimresponse"]
},
"identifier" : [{
"system" : "http://example.org/PATIENT_EVENT_TRACE_NUMBER",
"value" : "111099"
}],
"status" : "active",
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/claim-type",
"code" : "professional"
}]
},
"use" : "preauthorization",
"patient" : {
"reference" : "Patient/SubscriberExample"
},
"created" : "2005-05-02T11:02:00+05:00",
"insurer" : {
"reference" : "Organization/InsurerExample"
},
"requestor" : {
"reference" : "PractitionerRole/ReferralPractitionerRoleExample"
},
"request" : {
"reference" : "Claim/MedicalServicesAuthorizationExample"
},
"outcome" : "queued"
}
},
{
"fullUrl" : "http://example.org/fhir/Claim/MedicalServicesAuthorizationExample",
"resource" : {
"resourceType" : "Claim",
"id" : "MedicalServicesAuthorizationExample",
"meta" : {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim|2.1.0"
]
},
"identifier" : [{
"system" : "http://example.org/PATIENT_EVENT_TRACE_NUMBER",
"value" : "111099"
}
}],
"status" : "active",
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/claim-type",
"code" : "professional"
}]
},
"use" : "preauthorization",
"patient" : {
"reference" : "Patient/SubscriberExample"
},
"created" : "2005-05-02T11:01:00+05:00",
"insurer" : {
"reference" : "Organization/InsurerExample"
},
"provider" : {
"reference" : "Organization/UMOExample"
},
"priority" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/processpriority",
"code" : "normal"
}]
},
"insurance" : [{
"sequence" : 1,
"focal" : true,
"coverage" : {
"reference" : "Coverage/InsuranceExample"
}
}],
"item" : [{
"extension" : [{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-serviceItemRequestType",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1525",
"code" : "IN",
"display" : "Initial Medical Services Reservation"
}]
}
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-certificationType",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1322",
"code" : "I",
"display" : "Initial"
}]
}
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-authorizationNumber",
"valueString" : "1122344"
},
{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-administrationReferenceNumber",
"valueString" : "33441122"
}],
"sequence" : 1,
"category" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/1365",
"code" : "1",
"display" : "Medical Care"
}]
},
"productOrService" : {
"coding" : [{
"system" : "http://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets",
"code" : "99212",
"display" : "Established Office Visit"
}]
},
"servicedDate" : "2005-05-10",
"locationCodeableConcept" : {
"coding" : [{
"system" : "https://www.cms.gov/Medicare/Coding/place-of-service-codes/Place_of_Service_Code_Set",
"code" : "11"
}]
}
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Organization/UMOExample",
"resource" : {
"resourceType" : "Organization",
"id" : "UMOExample",
"meta" : {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-requestor|2.1.0"
]
},
"identifier" : [{
"system" : "http://hl7.org/fhir/sid/us-npi",
"value" : "8189991234"
}],
"active" : true,
"type" : [{
"coding" : [{
"system" : "https://codesystem.x12.org/005010/98",
"code" : "X3"
}]
}],
"name" : "DR. JOE SMITH CORPORATION",
"address" : [{
"line" : ["111 1ST STREET"],
"city" : "SAN DIEGO",
"state" : "CA",
"postalCode" : "92101",
"country" : "US"
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Organization/InsurerExample",
"resource" : {
"resourceType" : "Organization",
"id" : "InsurerExample",
"meta" : {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-insurer|2.1.0"
]
},
"identifier" : [{
"system" : "http://hl7.org/fhir/sid/us-npi",
"value" : "1234567893"
}],
"active" : true,
"type" : [{
"coding" : [{
"system" : "https://codesystem.x12.org/005010/98",
"code" : "PR"
}]
}],
"name" : "MARYLAND CAPITAL INSURANCE COMPANY"
}
},
{
"fullUrl" : "http://example.org/fhir/Coverage/InsuranceExample",
"resource" : {
"resourceType" : "Coverage",
"id" : "InsuranceExample",
"meta": {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-coverage",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-coverage|2.1.0"
]
},
"status" : "active",
"subscriberId" : "1122334455",
"beneficiary" : {
"reference" : "Patient/SubscriberExample"
},
"relationship" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/subscriber-relationship",
"code" : "self"
},
{
"system" : "https://codesystem.x12.org/005010/1069",
"code" : "18"
}]
},
"payor" : [{
"reference" : "Organization/InsurerExample"
}]
}
},
{
"fullUrl" : "http://example.org/fhir/Patient/SubscriberExample",
"resource" : {
"resourceType" : "Patient",
"id" : "SubscriberExample",
"meta": {
"profile": [
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-subscriber",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-beneficiary",
"http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-beneficiary|2.1.0"
]
},
"extension" : [{
"url" : "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-militaryStatus",
"valueCodeableConcept" : {
"coding" : [{
"system" : "https://codesystem.x12.org/005010/584",
"code" : "RU"
}]
}
}],
"identifier" : [{
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
"code" : "MB"
}]
},
"system" : "http://example.org/MIN",
"value" : "12345678901"
}],
"name" : [{
"family" : "SMITH",
"given" : ["JOE"]
}],
"gender" : "male"
}
}]
}
```
## Respostas de erro
### 400 solicitação inválida
Retornado quando o formato da solicitação é inválido ou está incorreto.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "invalid",
"diagnostics": "The provided payload was invalid and could not be parsed correctly."
}]
}
```
### 412 Falha na pré-condição
Retornado quando a mesma solicitação de autorização prévia já foi enviada (envio duplicado detectado).
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "processing",
"diagnostics": "PreAuth Claim already exists"
}]
}
```
**Idempotência**
A `$submit` operação é idempotente. Enviar a mesma solicitação várias vezes não criará solicitações de autorização prévia duplicadas. Em vez disso, você receberá um erro 412 solicitando que você use `$inquire` para verificar o status do seu envio original.
### 422 Entidade não processável
Retornado quando a validação do FHIR falha.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "required",
"diagnostics": "Bundle contains more than one preauthorization claim"
}]
}
```
## Regras de validação
HealthLake realiza uma validação abrangente em seu envio:
### Validação do pacote
+ Deve estar em conformidade com o perfil do PAS Request Bundle
+ `Bundle.type`deve ser `"collection"`
+ Pode conter vários recursos de reivindicação
+ No entanto, deve conter exatamente um recurso de reclamação com uso pré-autorizado
+ E esse recurso de reivindicação deve ser a primeira entrada no pacote
+ Todos os recursos referenciados devem ser incluídos no pacote
### Validação da solicitação
+ Deve estar em conformidade com o perfil de reclamação do PAS
+ `Claim.use`deve ser `"preauthorization"`
+ Campos obrigatórios: `patient``insurer`,,`provider`,`created`, `priority`
+ Os identificadores comerciais devem estar presentes e válidos
### Validação de recursos
+ Todos os recursos devem estar em conformidade com seus respectivos perfis PAS
+ Os recursos de apoio necessários devem estar presentes (paciente, cobertura, organização)
+ As referências cruzadas devem ser válidas e solucionáveis dentro do pacote
## Especificações de performance
| Métrica | Especificação |
| --- | --- |
| Limite de tamanho do pacote | Máximo de 5 MB |
| Limite de contagem de recursos | 500 recursos por pacote |
## Permissões obrigatórias
Para usar a `$submit` operação, é possível usar o AWS Sigv4 ou o SMART no FHIR:
+ Certifique-se de que sua função do IAM tenha: `healthlake:SubmitPreAuthClaim` - Para chamar a operação
**SMART em escopos FHIR**
**Escopos mínimos exigidos:**
+ **SMART v1:** `user/Claim.write & .write`
+ **SMART v2:** `user/Claim.c & .c or system/*.*`
## Notas de implementação importantes
### Persistência de recursos
+ Todas as entradas do pacote são mantidas como recursos individuais do FHIR em seu armazenamento de dados
+ Os fornecidos pelo cliente IDs são preservados quando fornecidos
+ O histórico de versões é mantido para fins de auditoria
+ A detecção de duplicatas evita conflitos de recursos
### Comportamento de processamento
+ Cada envio válido resulta em exatamente um ClaimResponse com `"queued"` resultado
+ Envios inválidos retornam códigos de status 400 ou 422 com informações detalhadas de erro
+ Os erros do sistema retornam os códigos de status 5xx apropriados
+ Todos os envios bem-sucedidos retornam o status 200 com um valor pendente ClaimResponse
### Requisitos do pacote
+ `Bundle.entry.fullUrl`os valores devem ser REST URLs ou `"urn:uuid:[guid]"` formatados
+ Todos GUIDs devem ser exclusivos em todos os envios (exceto nas mesmas instâncias de recursos)
+ Os recursos referenciados devem existir dentro do pacote ou ser solucionáveis
## Operações do relacionadas
+ `Claim/$inquire`- Consulte o status de uma solicitação de autorização prévia enviada
+ `Patient/$everything`- Recupere dados abrangentes do paciente para contexto de autorização prévia
# Validando recursos do FHIR com `$validate`
AWS HealthLake agora suporta a `$validate` operação de recursos FHIR, permitindo que você valide um recurso de acordo com a especificação FHIR e verifique sua conformidade com um perfil específico ou definição de recurso básico sem realizar nenhuma operação de armazenamento. Essa operação é particularmente útil quando você precisa:
+ Valide os requisitos de conformidade do FHIR CMS
+ Teste os recursos antes de usá-los na produção
+ Forneça feedback de validação em tempo real à medida que os usuários editam dados clínicos
+ Reduza os envios de dados inválidos para criar e atualizar APIs
## Usage
A `$validate` operação pode ser invocada em recursos FHIR usando métodos POST:
**Operações com Suporte**
```
POST [base]/[type]/[id]/$validate
POST [base]/[type]/$validate
```
## Cargas úteis suportadas
**Recurso de parâmetros**
HealthLake suporta os seguintes parâmetros FHIR: `$validate`
| Parâmetro | Tipo | Obrigatório | Description |
| --- | --- | --- | --- |
| resource | Recurso | Sim | O recurso a ser validado |
| profile | canônico | Não | URL canônico do perfil a ser validado |
| mode | código | Não | Modo de validação:create, ou update |
**Recurso direto com parâmetros de consulta**
| Parâmetro | Tipo | Obrigatório | Description |
| --- | --- | --- | --- |
| profile | canônico | Não | URL canônico do perfil a ser validado |
| mode | código | Não | Modo de validação:create, ou update |
## Exemplos
**Solicitação POST de recurso com ID e carga útil de parâmetros**
```
POST [base]/Patient/example-patient/$validate
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "resource",
"resource": {
"resourceType": "Patient",
"id": "example-patient",
"name": [
{
"family": "Smith",
"given": ["John"]
}
],
"gender": "male",
"birthDate": "1990-01-01"
}
},
{
"name": "profile",
"valueCanonical": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
},
{
"name": "mode",
"valueString": "create"
}
]
}
```
**Solicitação POST para tipo de recurso e carga útil de parâmetros**
```
POST [base]/Patient/$validate
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "resource",
"resource": {
"resourceType": "Patient",
"name": [
{
"family": "Doe",
"given": ["Jane"]
}
],
"gender": "female",
"birthDate": "1985-05-15"
}
},
{
"name": "profile",
"valueCanonical": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"
},
{
"name": "mode",
"valueString": "update"
}
]
}
```
**Solicitação POST de recurso com ID e carga direta de recursos**
```
POST [base]/Patient/example-patient/$validate?profile=http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient&mode=create
Content-Type: application/fhir+json
{
"resourceType": "Patient",
"id": "example-patient",
"name": [
{
"family": "Smith",
"given": ["John"]
}
],
"gender": "male",
"birthDate": "1990-01-01"
}
```
**Solicitação POST para tipo de recurso e carga direta do recurso**
```
POST [base]/Patient/$validate?profile=http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient&mode=create
Content-Type: application/fhir+json
{
"resourceType": "Patient",
"id": "example-patient",
"name": [
{
"family": "Smith",
"given": ["John"]
}
],
"gender": "male",
"birthDate": "1990-01-01"
}
```
**Resposta da amostra**
A operação retorna um OperationOutcome recurso com resultados de validação:
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Validation successful"
}
]
}
```
**Exemplo de resposta com erros de validação**
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "required",
"details": {
"text": "Missing required element"
},
"diagnostics": "Patient.identifier is required by the US Core Patient profile",
"location": [
"Patient.identifier"
]
},
{
"severity": "warning",
"code": "code-invalid",
"details": {
"text": "Invalid code value"
},
"diagnostics": "The provided gender code is not from the required value set",
"location": [
"Patient.gender"
]
}
]
}
```
## Comportamento
A `$validate` operação:
1. Valida o recurso em relação à especificação FHIR e à definição do recurso básico
1. Verifica a conformidade com os perfis especificados quando o `profile` parâmetro é fornecido
1. Valida com base no modo especificado (`create`ou`update`)
1. Retorna resultados detalhados da validação, incluindo erros, avisos e mensagens informativas
1. Não executa nenhuma operação de armazenamento - somente validação
1. Retorna HTTP 200 OK quando a validação pode ser realizada, independentemente de problemas de validação terem sido encontrados
## Modos de validação
+ **criar**: valida o recurso como se estivesse sendo criado (novo recurso)
+ **atualização**: valida o recurso como se estivesse sendo atualizado (recurso existente)
## Tratamento de erros
A operação retorna:
+ 200 OK: A validação foi realizada com sucesso (independentemente do resultado da validação)
+ 400 Solicitação inválida: formato ou parâmetros de solicitação inválidos
+ 404 Não encontrado: tipo de recurso ou perfil não encontrado
Para obter mais informações sobre a especificação da `$validate` operação, consulte a documentação do [recurso FHIR R4](https://www.hl7.org/fhir/R4/operation-resource-validate.html). `$validate`
# Referência de conformidade para AWS HealthLake
AWS HealthLake fornece recursos projetados para ajudá-lo a rastrear e relatar o uso da API de acordo com os requisitos de interoperabilidade do CMS (Centers for Medicare & Medicaid Services). Esses recursos permitem que você categorize as transações de API por categorias exigidas pelo CMS e capture automaticamente métricas de uso para fins de relatórios de conformidade.
**Entendendo suas responsabilidades de conformidade**
O uso AWS HealthLake de seus endpoints de interoperabilidade do CMS **não é suficiente por si só para alcançar a conformidade com o** CMS. Você é responsável por:
Mapeando corretamente seus fluxos de trabalho de API para os endpoints apropriados da categoria CMS com base em seus casos de uso específicos e obrigações regulatórias
Implementando controles adequados de autenticação e autorização que atendam aos requisitos do CMS
Garantir que seus recursos e trocas de dados do FHIR estejam em conformidade com os regulamentos e guias de implementação aplicáveis do CMS
Configurando e monitorando as CloudWatch métricas para atender às suas necessidades de relatórios de conformidade
Compreender quais regras do CMS se aplicam à sua organização e implementar os controles técnicos e operacionais apropriados
AWS HealthLake fornece a infraestrutura e as ferramentas para apoiar seus esforços de conformidade, mas você deve usar esses recursos adequadamente com base em seus requisitos regulatórios específicos. O simples roteamento de chamadas de API por meio desses endpoints não torna automaticamente seu aplicativo compatível com os regulamentos do CMS.
**Topics**
+ [CMS](reference-compliance-cms.md)
# 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
```
# Referência de suporte para AWS HealthLake
O seguinte material de referência de apoio está disponível para AWS HealthLake.
**nota**
Todas as HealthLake ações e tipos de dados nativos são descritos em uma referência separada. Para obter mais informações, consulte a [Referência da API do *AWS HealthLake *](https://docs.aws.amazon.com/healthlake/latest/APIReference/).
**Topics**
+ [Endpoints e cotas](reference-healthlake-endpoints-quotas.md)
+ [Tipos de dados pré-carregados](reference-healthlake-preloaded-data-types.md)
+ [Projetos de amostra](reference-healthlake-sample-projects.md)
+ [Solução de problemas](reference-healthlake-troubleshooting.md)
+ [Trabalhando com AWS SDKs](sdk-general-information-section.md)
# AWS HealthLake endpoints e cotas
Os tópicos a seguir contêm informações sobre pontos finais e cotas de AWS HealthLake serviço.
**Topics**
+ [Service endpoints](#reference-healthlake-endpoints)
+ [Cotas de serviço](#reference-healthlake-quotas)
## Service endpoints
Um endpoint de serviço é um URL que identifica um host e a porta como o ponto de entrada para um serviço web. Cada solicitação de serviço da web contém um endpoint. A maioria dos AWS serviços fornece endpoints para regiões específicas para permitir uma conectividade mais rápida. A tabela a seguir lista os endpoints de serviço para AWS HealthLake.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/healthlake/latest/devguide/reference-healthlake-endpoints-quotas.html)
## Cotas de serviço
As cotas de serviço são definidas como o valor máximo para recursos, ações e itens em sua AWS conta.
**nota**
É possível solicitar aumentos de cota para cotas ajustáveis do IAM usando o[ console do Service Quotas](https://console.aws.amazon.com/servicequotas/). Para obter mais informações, consulte [Solicitando um Aumento de Cota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) no * Guia do Usuário do Service Quotas*.
A taxa da API Sync Write aumenta proporcionalmente com o tamanho da carga, com cada incremento de 1 KB consumindo capacidade adicional (por exemplo, uma carga útil de 4 KB usa 4 vezes a capacidade de gravação). Definir o `x-amz-fhir-history-consistency-level` cabeçalho opcional para `strong` dobrar o consumo da capacidade de gravação por recurso.
Os recursos dos pacotes seguem read/write limites padrão com base no tamanho da carga útil de 1 KB. A *transação* do tipo pacote consome o dobro da capacidade de gravação em comparação com o tipo *lote*, o que significa que os pacotes *em lote* podem processar duas vezes mais recursos por segundo do que os pacotes de transação.
A tabela a seguir lista as cotas padrão para AWS HealthLake.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/healthlake/latest/devguide/reference-healthlake-endpoints-quotas.html)
# Tipos de dados pré-carregados do Synthea para HealthLake
HealthLake suporta somente SYNTHEA como um tipo de dados pré-carregado. [O Synthea é um](https://synthetichealth.github.io/synthea/) gerador sintético de pacientes que modela o histórico `Patient` médico. Ele está hospedado em um repositório Git de código aberto que HealthLake permite gerar um `Bundle` recurso compatível com FHIR R4 para que os usuários possam testar modelos sem usar dados reais do paciente.
Os seguintes tipos de recursos estão disponíveis em armazenamentos de HealthLake dados pré-carregados. Para obter mais informações sobre o pré-carregamento de armazenamentos HealthLake de dados com dados Synthea, consulte. [Criando um armazenamento HealthLake de dados](managing-data-stores-create.md)
**nota**
Para ver uma lista completa dos recursos HealthLake compatíveis com o FHIR R4, consulte. [Tipos de recursos compatíveis com FHIR R4 para HealthLake](reference-fhir-resource-types.md)
**Tipos de recursos Synthea FHIR suportados por HealthLake**
| | |
| --- |--- |
| AllergyIntolerance | Local |
| CarePlan | MedicationAdministration |
| CareTeam | MedicationRequest |
| Reivindicar | Observação |
| Condição | Organização |
| Dispositivo | Paciente |
| DiagnosticReport | Praticante |
| Encontro | PractitionerRole |
| ExplanationofBenefit | Procedimento |
| ImagingStudy | Proveniência |
| Imunização | |
# AWS HealthLake projetos de amostra
Para aprofundar sua análise, você pode usar HealthLake com outros AWS serviços, conforme demonstrado nos exemplos de postagens de blog a seguir.
**HealthLake análise integrada**
+ [Aplicativos de saúde populacional com AWS HealthLake — Parte 1: Análise e monitoramento usando o Amazon Quick](https://aws.amazon.com/blogs/machine-learning/population-health-applications-with-amazon-healthlake-part-1-analytics-and-monitoring-using-amazon-quicksight/).
+ [Criação de modelos preditivos de doenças usando Amazon SageMaker AI com dados AWS HealthLake normalizados](https://aws.amazon.com/blogs/machine-learning/building-predictive-disease-models-using-amazon-sagemaker-with-amazon-healthlake-normalized-data/).
+ [Crie uma pesquisa cognitiva e um gráfico de conhecimento de saúde usando serviços de AWS IA](https://aws.amazon.com/blogs/machine-learning/build-a-cognitive-search-and-a-health-knowledge-graph-using-amazon-healthlake-amazon-kendra-and-amazon-neptune/).
**HealthLake monitoramento de eventos**
+ [ EventBridge Integração da Amazon com AWS HealthLake](https://aws.amazon.com/blogs/industries/amazon-eventbridge-integration-for-aws-healthlake/).
# Solução de problemas AWS HealthLake
Os tópicos a seguir fornecem dicas de solução de problemas para erros e problemas que você pode encontrar ao usar o HealthLake console AWS CLI AWS SDKs, ou. Se você encontrar um problema que não esteja listado nesta seção, use o botão **Fornecer feedback** na barra lateral direita desta página para denunciá-lo.
**Topics**
+ [Ações do armazenamento de dados](#troubleshooting-data-store)
+ [Importar ações](#troubleshooting-import)
+ [FHIR APIs](#troubleshooting-fhir-apis)
+ [Integrações de PNL](#troubleshooting-nlp-integrations)
+ [Integrações SQL](#troubleshooting-sql-integrations)
## Ações do armazenamento de dados
**Problema:** *quando tento criar um armazenamento de HealthLake dados, recebo o seguinte erro:*
```
AccessDeniedException: Insufficient Lake Formation permission(s): Required Database on Catalog
```
Em 14 de novembro de 2022, HealthLake atualizei as permissões necessárias do IAM para criar um novo armazenamento de dados. Para obter mais informações, consulte [Configurar um usuário ou uma função do IAM para usar HealthLake (administrador do IAM)](getting-started-setting-up.md#setting-up-configure-iam).
**Problema:** *Ao criar um armazenamento de HealthLake dados usando o AWS SDKs, o status de criação do armazenamento de dados retorna uma exceção ou um status desconhecido.*
Atualize seu AWS SDK para a versão mais recente se suas chamadas `DescribeFHIRDatastore` ou de `ListFHIRDatastores` API retornarem uma exceção ou um status desconhecido do armazenamento de dados.
## Importar ações
**Problema:** *ainda posso usar HealthLake se meus dados não estiverem no formato FHIR R4*?
Somente dados formatados em FHIR R4 podem ser importados para um armazenamento de dados. HealthLake [Para obter uma lista de parceiros que podem ajudar a transformar os dados de saúde existentes no formato FHIR R4, consulte Parceiros.AWS HealthLake](https://docs.aws.amazon.com/healthlake/partners/)
**Problema:** *Por que meu trabalho de importação do FHIR falhou*?
Um trabalho de importação bem-sucedido gerará uma pasta com resultados (log de saída) no `.ndjson` formato, no entanto, registros individuais podem falhar na importação. Quando isso acontecer, uma segunda `FAILURE` pasta será gerada com um manifesto de registros que falharam na importação. Para obter mais informações, consulte [Importando dados FHIR com AWS HealthLake](importing-fhir-data.md).
Para analisar por que um trabalho de importação falhou, use a `DescribeFHIRImportJob` API para analisar JobProperties o. O seguinte é recomendado:
+ Se o status for `FAILED` e uma mensagem estiver presente, as falhas estão relacionadas a parâmetros do trabalho, como tamanho dos dados de entrada ou número de arquivos de entrada, que estão além das HealthLake cotas.
+ Se o status do trabalho de importação for`COMPLETED_WITH_ERRORS`, verifique o arquivo de manifesto,`manifest.json`, para obter informações sobre quais arquivos não foram importados com êxito.
+ Se o status do trabalho de importação for `FAILED` e uma mensagem não estiver presente, vá até o local de saída do trabalho para acessar o arquivo de manifesto,`manifest.json`.
Para cada arquivo de entrada, há um arquivo de saída de falha com o nome do arquivo de entrada para qualquer recurso que falhe na importação. As respostas contêm o número da linha (lineID) correspondente à localização dos dados de entrada, objeto de resposta FHIR (UpdateResourceResponse) e código de status (statusCode) da resposta.
Um exemplo de arquivo de saída pode ser semelhante ao seguinte:
```
{"lineId":3, UpdateResourceResponse:{"jsonBlob":{"resourceType":"OperationOutcome","issue":[{"severity":"error","code":"processing","diagnostics":"1 validation error detected: Value 'Patient123' at 'resourceType' failed to satisfy constraint: Member must satisfy regular expression pattern: [A-Za-z]{1,256}"}]}, "statusCode":400}
{"lineId":5, UpdateResourceResponse:{"jsonBlob":{"resourceType":"OperationOutcome","issue":[{"severity":"error","code":"processing","diagnostics":"This property must be an simple value, not a com.google.gson.JsonArray","location":["/EffectEvidenceSynthesis/name"]},{"severity":"error","code":"processing","diagnostics":"Unrecognised property '@telecom'","location":["/EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Unrecognised property '@gender'","location":["/EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Unrecognised property '@birthDate'","location":["/EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Unrecognised property '@address'","location":["/EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Unrecognised property '@maritalStatus'","location":["/EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Unrecognised property '@multipleBirthBoolean'","location":["/EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Unrecognised property '@communication'","location":["/EffectEvidenceSynthesis"]},{"severity":"warning","code":"processing","diagnostics":"Name should be usable as an identifier for the module by machine processing applications such as code generation [name.matches('[A-Z]([A-Za-z0-9_]){0,254}')]","location":["EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Profile http://hl7.org/fhir/StructureDefinition/EffectEvidenceSynthesis, Element 'EffectEvidenceSynthesis.status': minimum required = 1, but only found 0","location":["EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Profile http://hl7.org/fhir/StructureDefinition/EffectEvidenceSynthesis, Element 'EffectEvidenceSynthesis.population': minimum required = 1, but only found 0","location":["EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Profile http://hl7.org/fhir/StructureDefinition/EffectEvidenceSynthesis, Element 'EffectEvidenceSynthesis.exposure': minimum required = 1, but only found 0","location":["EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Profile http://hl7.org/fhir/StructureDefinition/EffectEvidenceSynthesis, Element 'EffectEvidenceSynthesis.exposureAlternative': minimum required = 1, but only found 0","location":["EffectEvidenceSynthesis"]},{"severity":"error","code":"processing","diagnostics":"Profile http://hl7.org/fhir/StructureDefinition/EffectEvidenceSynthesis, Element 'EffectEvidenceSynthesis.outcome': minimum required = 1, but only found 0","location":["EffectEvidenceSynthesis"]},{"severity":"information","code":"processing","diagnostics":"Unknown extension http://synthetichealth.github.io/synthea/disability-adjusted-life-years","location":["EffectEvidenceSynthesis.extension[3]"]},{"severity":"information","code":"processing","diagnostics":"Unknown extension http://synthetichealth.github.io/synthea/quality-adjusted-life-years","location":["EffectEvidenceSynthesis.extension[4]"]}]}, "statusCode":400}
{"lineId":7, UpdateResourceResponse:{"jsonBlob":{"resourceType":"OperationOutcome","issue":[{"severity":"error","code":"processing","diagnostics":"2 validation errors detected: Value at 'resourceId' failed to satisfy constraint: Member must satisfy regular expression pattern: [A-Za-z0-9-.]{1,64}; Value at 'resourceId' failed to satisfy constraint: Member must have length greater than or equal to 1"}]}, "statusCode":400}
{"lineId":9, UpdateResourceResponse:{"jsonBlob":{"resourceType":"OperationOutcome","issue":[{"severity":"error","code":"processing","diagnostics":"Missing required id field in resource json"}]}, "statusCode":400}
{"lineId":15, UpdateResourceResponse:{"jsonBlob":{"resourceType":"OperationOutcome","issue":[{"severity":"error","code":"processing","diagnostics":"Invalid JSON found in input file"}]}, "statusCode":400}
```
O exemplo acima mostra que houve falhas nas linhas 3, 4, 7, 9, 15 das linhas de entrada correspondentes do arquivo de entrada. Para cada uma dessas linhas, as explicações são as seguintes:
+ Na linha 3, a resposta explica que o `resourceType` fornecido na linha 3 do arquivo de entrada não é válido.
+ Na linha 5, a resposta explica que há um erro de validação FHIR na linha 5 do arquivo de entrada.
+ Na linha 7, a resposta explica que há um problema de validação com o `resourceId` fornecimento como entrada.
+ Na linha 9, a resposta explica que o arquivo de entrada deve conter um ID de recurso válido.
+ Na linha 15, a resposta do arquivo de entrada é que o arquivo não está em um formato JSON válido.
## FHIR APIs
**Problema:** *Como faço para implementar a autorização para o FHIR RESTful APIs*?
Determine o [Estratégia de autorização do armazenamento de dados](getting-started-concepts.md#concept-data-store-authorization-strategy) a ser usado.
Para criar a autorização SigV4 usando o AWS SDK para Python (Boto3), crie um script semelhante ao exemplo a seguir.
```
import boto3
import requests
import json
from requests_auth_aws_sigv4 import AWSSigV4
# Set the input arguments
data_store_endpoint = 'https://healthlake.us-east-1.amazonaws.com/datastore//r4//'
resource_path = "Patient"
requestBody = {"resourceType": "Patient", "active": True, "name": [{"use": "official","family": "Dow","given": ["Jen"]},{"use": "usual","given": ["Jen"]}],"gender": "female","birthDate": "1966-09-01"}
region = 'us-east-1'
#Frame the resource endpoint
resource_endpoint = data_store_endpoint+resource_path
session = boto3.session.Session(region_name=region)
client = session.client("healthlake")
# Frame authorization
auth = AWSSigV4("healthlake", session=session)
# Call data store FHIR endpoint using SigV4 auth
r = requests.post(resource_endpoint, json=requestBody, auth=auth, )
print(r.json())
```
**Problema:** *Por que estou recebendo `AccessDenied` erros ao usar o FHIR RESTful APIs para um armazenamento de dados criptografado com uma chave KMS gerenciada pelo cliente*?
As permissões para chaves gerenciadas pelo cliente e políticas do IAM são necessárias para que um usuário ou função acesse um armazenamento de dados. Um usuário deve ter as permissões necessárias do IAM para usar uma chave gerenciada pelo cliente. Se um usuário revogou ou retirou uma concessão que dava HealthLake permissão para usar a chave KMS gerenciada pelo cliente, HealthLake retornará um `AccessDenied` erro.
HealthLake deve ter a permissão para acessar os dados do cliente, criptografar novos recursos do FHIR importados para um armazenamento de dados e descriptografar os recursos do FHIR quando solicitados. Para obter mais informações, consulte [Solução de problemas de AWS KMS permissões](https://docs.aws.amazon.com/kms/latest/developerguide/policy-evaluation.html).
**Problema:** *uma operação `POST` da API FHIR HealthLake usando um documento de 10 MB está retornando o* erro. `413 Request Entity Too Large`
AWS HealthLake tem um limite síncrono de criação e atualização da API de 5 MB para evitar maiores latências e tempos limite. Você pode ingerir documentos grandes, de até 164 MB, usando o tipo de `Binary` recurso usando a API de importação em massa.
## Integrações de PNL
**Problema:** *Como faço para ativar HealthLake o recurso integrado de processamento de linguagem natural do?*
Em 14 de novembro de 2022, o comportamento padrão dos armazenamentos de HealthLake dados mudou.
**Armazenamentos de dados atuais**: todos os armazenamentos de HealthLake dados atuais deixarão de usar o processamento de linguagem natural (NLP) em recursos codificados em base64`DocumentReference`. Isso significa que novos `DocumentReference` recursos não serão analisados usando a PNL e nenhum novo recurso será gerado com base no texto do tipo de `DocumentReference` recurso. Para `DocumentReference` os recursos existentes, os dados e recursos gerados via PNL permanecem, mas não serão atualizados após 20 de fevereiro de 2023.
**Novos armazenamentos de HealthLake dados**: os armazenamentos de dados criados após 20 de fevereiro de 2023 *não* executarão processamento de linguagem natural (NLP) em recursos codificados em base64`DocumentReference`.
Para ativar a integração HealthLake da PNL, crie um caso de suporte usando [AWS Support Center Console](https://console.aws.amazon.com/support/home#/). Para criar seu caso, faça login no seu Conta da AWS e escolha **Criar caso**. Para saber mais sobre a criação de um caso e o gerenciamento de casos, consulte [Criação de casos de suporte e gerenciamento de](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) casos no *Guia Suporte do usuário*.
**Problema:** *>Como faço para encontrar `DocumentReference` recursos que não puderam ser processados pela PNL integrada*?
Se um `DocumentReference` recurso não for válido, HealthLake fornece uma extensão indicando um erro de validação em vez de fornecê-la na saída médica integrada de PNL. **Para encontrar `DocumentReference` recursos que levaram a um erro de validação durante o processamento da PNL, você pode usar a `search` função FHIR com a chave HealthLake de pesquisa **cm-decoration-status**e o valor de pesquisa VALIDATION\$1ERROR.** Essa pesquisa listará todos os `DocumentReference` recursos que levaram a erros de validação, junto com uma mensagem de erro descrevendo a natureza do erro. A estrutura do campo de extensão nesses `DocumentReference` recursos com erros de validação será semelhante ao exemplo a seguir.
```
"extension": [
{
"extension": [
{
"url": "http://healthlake.amazonaws.com/aws-cm/status/",
"valueString": "VALIDATION_ERROR"
},
{
"url": "http://healthlake.amazonaws.com/aws-cm/message/",
"valueString": "Resource led to too many nested objects after NLP operation processed the document. 10937 nested objects exceeds the limit of 10000."
}
],
"url": "http://healthlake.amazonaws.com/aws-cm/"
}
]
```
**nota**
A também `VALIDATION_ERROR` pode ocorrer se a decoração de PNL criar mais de 10.000 objetos aninhados. Quando isso acontece, o documento deve ser dividido em documentos menores antes do processamento.
## Integrações SQL
**Problema:** *Por que recebo um Lake Formation `permissions error: lakeformation:PutDataLakeSettings` ao adicionar um novo administrador de data lake?*
Se seu usuário ou função do IAM contiver a política `AWSLakeFormationDataAdmin` AWS gerenciada, você não poderá adicionar novos administradores de data lake. Você receberá um erro contendo o seguinte:
```
User arn:aws:sts::111122223333:assumed-role/lakeformation-admin-user is not authorized to perform: lakeformation:PutDataLakeSettings on resource: arn:aws:lakeformation:us-east-2:111122223333:catalog:111122223333 with an explicit deny in an identity-based policy
```
A política AWS gerenciada `AdministratorAccess` é necessária para adicionar um usuário ou uma função do IAM como administrador de data lake do AWS Lake Formation. Se seu usuário ou função do IAM também contiver`AWSLakeFormationDataAdmin`, a ação falhará. A política `AWSLakeFormationDataAdmin` AWS gerenciada contém uma negação explícita da operação da API AWS Lake Formation,`PutDataLakeSetting`. Até mesmo administradores com acesso total ao AWS uso da política `AdministratorAccess` gerenciada podem ser limitados pela `AWSLakeFormationDataAdmin` política.
**Problema:** *Como faço para migrar um HealthLake datastore existente para usar a integração do Amazon Athena SQL*?
HealthLake os armazenamentos de dados criados antes de 14 de novembro de 2022 são funcionais, mas não podem ser consultados no Athena usando SQL. Para consultar um armazenamento de dados preexistente com o Athena, você deve primeiro migrá-lo para um novo armazenamento de dados.
**Para migrar seus HealthLake dados para um novo armazenamento de dados**
1. Crie um novo armazenamento de dados.
1. Exporte os dados do pré-existente para um bucket do Amazon S3.
1. Importe os dados para o novo armazenamento de dados do bucket do Amazon S3.
**nota**
A exportação de dados para um bucket do Amazon S3 incorre em uma taxa extra. A taxa extra depende do tamanho dos dados que você exporta.
**Problema:** *ao criar um novo armazenamento de HealthLake dados para integração com SQL, o status do armazenamento de dados não muda de`Creating`.*
Se você tentar criar um novo armazenamento de HealthLake dados e o status do armazenamento de dados não mudar de **Criando**, você precisará atualizar o Athena para usar o. AWS Glue Data Catalog Para obter mais informações, consulte [Atualização para o catálogo de dados AWS Glue step-by-step no Guia](https://docs.aws.amazon.com/athena/latest/ug/glue-upgrade.html) do usuário do *Amazon Athena*.
Depois de atualizar com sucesso o AWS Glue Data Catalog, você pode criar um armazenamento de HealthLake dados.
Para remover um armazenamento de HealthLake dados antigo, crie um caso de suporte usando [AWS Support Center Console](https://console.aws.amazon.com/support/home#/). Para criar seu caso, faça login no seu Conta da AWS e escolha **Criar caso**. Para saber mais, consulte [Criação de casos de suporte e gerenciamento de casos](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) no *Guia Suporte do usuário*.
**Problema:** *o console do Athena não está funcionando depois de importar dados para um novo armazenamento de dados HealthLake *
Depois de importar dados para um novo armazenamento de HealthLake dados, os dados podem não estar disponíveis para uso imediato. Isso é para dar tempo para que os dados sejam ingeridos nas tabelas do Apache Iceberg. Tente novamente mais tarde.
**Problema:** *Como faço para conectar os resultados da pesquisa no Athena a outros AWS serviços*?
Ao compartilhar seus resultados de pesquisa do Athena com outros AWS serviços, podem ocorrer problemas quando você usa `json_extract[1]` como parte de uma consulta de pesquisa SQL. Para corrigir esse problema, você deve atualizar para `CATVAR` o.
Você pode encontrar esse problema ao tentar **criar** resultados salvos, uma **tabela** (estática) ou uma **exibição** (dinâmica).
# Usando HealthLake com um AWS SDK
AWS kits de desenvolvimento de software (SDKs) estão disponíveis para muitas linguagens de programação populares. Cada SDK fornece uma API, exemplos de código e documentação que permitem que os desenvolvedores criem facilmente aplicações em seu idioma de preferência.
| Documentação do SDK | Exemplos de código |
| --- | --- |
| [AWS SDK para C\$1\$1](https://docs.aws.amazon.com/sdk-for-cpp) | [AWS SDK para C\$1\$1 exemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp) |
| [AWS CLI](https://docs.aws.amazon.com/cli) | [AWS CLI exemplos de código](https://docs.aws.amazon.com/code-library/latest/ug/cli_2_code_examples.html) |
| [AWS SDK para Go](https://docs.aws.amazon.com/sdk-for-go) | [AWS SDK para Go exemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/gov2) |
| [AWS SDK para Java](https://docs.aws.amazon.com/sdk-for-java) | [AWS SDK para Java exemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2) |
| [AWS SDK para JavaScript](https://docs.aws.amazon.com/sdk-for-javascript) | [AWS SDK para JavaScript exemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3) |
| [AWS SDK para Kotlin](https://docs.aws.amazon.com/sdk-for-kotlin) | [AWS SDK para Kotlin exemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/kotlin) |
| [AWS SDK para .NET](https://docs.aws.amazon.com/sdk-for-net) | [AWS SDK para .NET exemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3) |
| [AWS SDK para PHP](https://docs.aws.amazon.com/sdk-for-php) | [AWS SDK para PHP exemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/php) |
| [Ferramentas da AWS para PowerShell](https://docs.aws.amazon.com/powershell) | [Ferramentas da AWS para PowerShell exemplos de código](https://docs.aws.amazon.com/code-library/latest/ug/powershell_5_code_examples.html) |
| [AWS SDK para Python (Boto3)](https://docs.aws.amazon.com/pythonsdk) | [AWS SDK para Python (Boto3) exemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python) |
| [AWS SDK para Ruby](https://docs.aws.amazon.com/sdk-for-ruby) | [AWS SDK para Ruby exemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby) |
| [AWS SDK para Rust](https://docs.aws.amazon.com/sdk-for-rust) | [AWS SDK para Rust exemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1) |
| [AWS SDK para SAP ABAP](https://docs.aws.amazon.com/sdk-for-sapabap) | [AWS SDK para SAP ABAP exemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/sap-abap) |
| [AWS SDK para Swift](https://docs.aws.amazon.com/sdk-for-swift) | [AWS SDK para Swift exemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/swift) |
**Exemplo de disponibilidade**
Não consegue encontrar o que precisa? Solicite um exemplo de código usando o link **Fornecer feedback** na parte inferior desta página.