Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# AWS HealthLake referencia
El siguiente material de referencia de apoyo está disponible para SMART sobre el FHIR, el FHIR y. AWS HealthLake
**nota**
Todas las HealthLake acciones y tipos de datos nativos se describen en una referencia independiente. Para obtener más información, consulte la [Referencia de la API de *AWS HealthLake *](https://docs.aws.amazon.com/healthlake/latest/APIReference/).
**Topics**
+ [SMART sobre el FHIR](reference-smart-on-fhir.md)
+ [FHIR R4](reference-fhir.md)
+ [Conformidad](reference-compliance.md)
+ [HealthLake](reference-healthlake.md)
# SMART sobre el apoyo del FHIR a AWS HealthLake
Un almacén de HealthLake datos habilitado para aplicaciones médicas y tecnologías reutilizables (SMART) compatible con el FHIR permite el acceso a aplicaciones compatibles con SMART en el FHIR. HealthLake Se accede a los datos autenticando y autorizando las solicitudes mediante un servidor de autorización externo. Por lo tanto, en lugar de administrar las credenciales de los usuarios mediante AWS Identity and Access Management, lo hace utilizando un servidor de autorización compatible con SMART on FHIR.
**nota**
HealthLake es compatible con SMART en las versiones 1.0 y 2.0 del FHIR. Para obtener más información sobre estos marcos, consulte el [lanzamiento de la aplicación SMART](https://www.hl7.org/fhir/smart-app-launch/) en la documentación del *FHIR R4*.
HealthLake los almacenes de datos admiten los siguientes marcos de autenticación y autorización para SMART en las solicitudes del FHIR:
**OpenID (AuthN)**: para autenticar que la persona o la aplicación cliente es quien (o qué) dice ser.
**OAuth 2.0 (AuthZ)**: para autorizar qué recursos del FHIR de su almacén de HealthLake datos puede leer o escribir una solicitud autenticada. Esto se define mediante los ámbitos configurados en su servidor de autorización.
Puede crear un almacén de datos compatible con SMART on FHIR mediante la AWS CLI tecla o. AWS SDKs Para obtener más información, consulte [Creación de un almacén HealthLake de datos](managing-data-stores-create.md).
**Topics**
+ [Cómo empezar a usar SMART en FHIR](reference-smart-on-fhir-getting-started.md)
+ [HealthLake requisitos de autenticación para SMART en FHIR](reference-smart-on-fhir-authentication.md)
+ [Los osciloscopios SMART on FHIR OAuth 2.0 son compatibles con HealthLake](reference-smart-on-fhir-oauth-scopes.md)
+ [Validación de token mediante AWS Lambda](reference-smart-on-fhir-token-validation.md)
+ [Uso de una autorización detallada con un almacén de datos habilitado para SMART on FHIR HealthLake](reference-smart-on-fhir-fine-grained-authorization.md)
+ [Obtención del documento de descubrimiento SMART on FHIR](reference-smart-on-fhir-discovery-document.md)
+ [Realizar una solicitud a la API REST de FHIR en un almacén de datos habilitado para SMART HealthLake](reference-smart-on-fhir-request-example.md)
# Cómo empezar a usar SMART en FHIR
En los siguientes temas se describe cómo empezar a utilizar SMART con la autorización del FHIR para. AWS HealthLake Incluyen los recursos que debe aprovisionar en su AWS cuenta, la creación de un almacén de HealthLake datos habilitado para SMART on FHIR y un ejemplo de cómo una aplicación cliente SMART on FHIR interactúa con un servidor de autorización y un almacén de datos. HealthLake
**Topics**
+ [Configuración de los recursos para SMART en el FHIR](#smart-on-fhir-resources)
+ [Flujo de trabajo de aplicaciones cliente para SMART on FHIR](#smart-on-fhir-client-app-workflow)
## Configuración de los recursos para SMART en el FHIR
Los siguientes pasos definen cómo gestionan las solicitudes SMART on FHIR HealthLake y los recursos necesarios para que tengan éxito. Los siguientes elementos se combinan en un flujo de trabajo para crear una solicitud SMART ante la FHIR:
+ **El usuario final**: por lo general, un paciente o un médico que utiliza una aplicación SMART on FHIR de terceros para acceder a los datos de un almacén de datos. HealthLake
+ **La aplicación SMART on FHIR (denominada aplicación cliente): una aplicación** que desea acceder a los datos que se encuentran en el almacén de datos. HealthLake
+ **El servidor de autorización**: un servidor compatible con OpenID Connect que puede autenticar a los usuarios y emitir tokens de acceso.
+ **El almacén de HealthLake datos**: un almacén de HealthLake datos habilitado para SMART on FHIR que utiliza una función Lambda para responder a las solicitudes REST del FHIR que proporcionan un token portador.
Para que estos elementos funcionen juntos, debe crear los siguientes recursos.
**nota**
Le recomendamos que cree su almacén de HealthLake datos compatible con SMART on FHIR una vez que haya configurado el servidor de autorización, definido los [alcances](reference-smart-on-fhir-oauth-scopes.md) necesarios y creado una AWS Lambda función para gestionar la introspección [simbólica](reference-smart-on-fhir-token-validation.md).
**1. Configure un punto final del servidor de autorización**
Para utilizar el marco SMART on FHIR, debe configurar un servidor de autorización externo que pueda validar las solicitudes REST del FHIR realizadas en un almacén de datos. Para obtener más información, consulte [HealthLake requisitos de autenticación para SMART en FHIR](reference-smart-on-fhir-authentication.md).
**2. Defina los ámbitos de su servidor de autorización para controlar los niveles de acceso a HealthLake los almacenes de datos**
El marco SMART on FHIR utiliza los OAuth alcances para determinar a qué recursos del FHIR tiene acceso una solicitud autenticada y en qué medida. Definir los ámbitos es una forma de diseñar pensando en los privilegios mínimos. Para obtener más información, consulte [Los osciloscopios SMART on FHIR OAuth 2.0 son compatibles con HealthLake](reference-smart-on-fhir-oauth-scopes.md).
**3. Configure una AWS Lambda función capaz de realizar una introspección simbólica**
Una solicitud REST del FHIR enviada por la aplicación cliente a un almacén de datos habilitado para SMART on FHIR contiene un token web JSON (JWT). Para obtener más información, consulte [Decodificar](reference-smart-on-fhir-token-validation.md) un JWT.
**4. Cree un almacén de datos compatible HealthLake con SMART en FHIR**
Para crear un almacén de HealthLake datos SMART en el FHIR, debe proporcionar un. `IdentityProviderConfiguration` Para obtener más información, consulte [Creación de un almacén HealthLake de datos](managing-data-stores-create.md).
## Flujo de trabajo de aplicaciones cliente para SMART on FHIR
En la siguiente sección se explica cómo lanzar una aplicación cliente y realizar una solicitud REST del FHIR correcta en un almacén de HealthLake datos en el contexto de SMART on FHIR.
**1. Realice una `GET` solicitud a Known Uniform Resource Identifier mediante una aplicación cliente**
Una aplicación cliente compatible con SMART debe realizar una `GET` solicitud para encontrar los puntos finales de autorización de su almacén de HealthLake datos. Esto se hace mediante una solicitud de identificador uniforme de recursos (URI) bien conocido. Para obtener más información, consulte [Obtención del documento de descubrimiento SMART on FHIR](reference-smart-on-fhir-discovery-document.md).
**2. Solicita el acceso y los alcances**
La aplicación cliente utiliza el punto final de autorización del servidor de autorización para que el usuario pueda iniciar sesión. Este proceso autentica al usuario. Los ámbitos se utilizan para definir a qué recursos del FHIR del almacén de HealthLake datos puede acceder una aplicación cliente. Para obtener más información, consulte [Los osciloscopios SMART on FHIR OAuth 2.0 son compatibles con HealthLake](reference-smart-on-fhir-oauth-scopes.md).
**3. Tokens de acceso**
Ahora que el usuario se ha autenticado, una aplicación cliente recibe un token de acceso JWT del servidor de autorización. Este token se proporciona cuando la aplicación cliente envía una solicitud REST del FHIR a. HealthLake Para obtener más información, consulte [Validación de tókenes](reference-smart-on-fhir-token-validation.md).
**4. Realice una solicitud a la API REST del FHIR en SMART, en un almacén de datos compatible con el FHIR HealthLake**
La aplicación cliente ahora puede enviar una solicitud de API REST del FHIR a un punto final del almacén de HealthLake datos mediante el token de acceso proporcionado por el servidor de autorización. Para obtener más información, consulte [Realizar una solicitud a la API REST de FHIR en un almacén de datos habilitado para SMART HealthLake](reference-smart-on-fhir-request-example.md).
**5. Valide el token de acceso JWT**
Para validar el token de acceso enviado en la solicitud REST del FHIR, utilice una función Lambda. Para obtener más información, consulte [Validación de token mediante AWS Lambda](reference-smart-on-fhir-token-validation.md).
# HealthLake requisitos de autenticación para SMART en FHIR
Para acceder a los recursos del FHIR en un almacén de HealthLake datos compatible con SMART o FHIR, una aplicación cliente debe estar autorizada por un servidor de autorización OAuth compatible con la versión 2.0 y presentar un token de OAuth portador como parte de una solicitud de la API REST del FHIR. Para encontrar el punto final del servidor de autorización, utilice el documento de descubrimiento HealthLake SMART on FHIR mediante un identificador de recursos uniforme. `Well-Known` Para obtener más información sobre este proceso, consulte [Obtención del documento de descubrimiento SMART on FHIR](reference-smart-on-fhir-discovery-document.md).
Al crear un banco de HealthLake datos SMART en el FHIR, debe definir el punto final del servidor de autorización y el punto final del token en el `metadata` elemento de la `CreateFHIRDatastore` solicitud. Para obtener más información sobre la definición del `metadata` elemento, consulte[Creación de un almacén HealthLake de datos](managing-data-stores-create.md).
Mediante los puntos finales del servidor de autorización, la aplicación cliente autenticará a un usuario con el servicio de autorización. Una vez autorizado y autenticado, el servicio de autorización genera un token web JSON (JWT) y lo pasa a la aplicación cliente. Este token contiene los ámbitos de recursos del FHIR que la aplicación cliente puede utilizar, lo que a su vez restringe los datos a los que puede acceder el usuario. Opcionalmente, si se proporcionó el alcance del lanzamiento, la respuesta contendrá esos detalles. Para obtener más información sobre los osciloscopios SMART on FHIR compatibles HealthLake, consulte. [Los osciloscopios SMART on FHIR OAuth 2.0 son compatibles con HealthLake](reference-smart-on-fhir-oauth-scopes.md)
Con el JWT otorgado por el servidor de autorización, una aplicación cliente realiza llamadas a la API REST del FHIR a un almacén de datos SMART que esté habilitado para el FHIR. HealthLake Para validar y decodificar el JWT, debe crear una función Lambda. HealthLake invoca esta función Lambda en su nombre cuando se recibe una solicitud de la API REST del FHIR. Para ver un ejemplo de función Lambda de inicio, consulte. [Validación de token mediante AWS Lambda](reference-smart-on-fhir-token-validation.md)
## Elementos del servidor de autorización necesarios para crear un almacén de datos compatible HealthLake con SMART on FHIR
En la `CreateFHIRDatastore` solicitud, debes proporcionar el punto final de autorización y el punto final del token como parte del `metadata` elemento del `IdentityProviderConfiguration` objeto. Se requieren tanto el punto final de autorización como el punto final del token. Para ver un ejemplo de cómo se especifica esto en `CreateFHIRDatastore` una solicitud, consulte[Creación de un almacén HealthLake de datos](managing-data-stores-create.md).
## Reclamaciones obligatorias para completar una solicitud de API REST del FHIR en un almacén de datos habilitado para SMART o FHIR HealthLake
Su AWS Lambda función debe contener las siguientes afirmaciones para que sea una solicitud de API REST del FHIR válida en un almacén de datos compatible con SMART on FHIR. HealthLake
+ `nbf`: Reclamación [(no anterior): la afirmación](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.5) «nbf» (no anterior) identifica el momento antes del cual NO SE DEBE aceptar el procesamiento del JWT. La tramitación de la reclamación «nbf» requiere que la actual date/time DEBE ser igual o igual a la cifra no date/time indicada anteriormente en la reclamación «nbf». La función Lambda de ejemplo que proporcionamos convierte la respuesta `iat` del servidor en. `nbf`
+ `exp`: [(fecha de caducidad): la afirmación](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4) «exp» (fecha de caducidad) identifica la fecha de caducidad a partir de la cual no se debe aceptar el JWT para su procesamiento.
+ `isAuthorized`: Un booleano establecido en. `True` Indica que la solicitud se ha autorizado en el servidor de autorización.
+ `aud`Afirmación: [(audiencia): la afirmación](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3) «aud» (audiencia) identifica a los destinatarios a los que está destinado el JWT. Debe ser un terminal de almacenamiento de HealthLake datos compatible con SMART on FHIR.
+ `scope`: Debe ser al menos un ámbito relacionado con los recursos del FHIR. Este ámbito se define en su servidor de autorización. Para obtener más información sobre los ámbitos relacionados con los recursos del FHIR aceptados por HealthLake, consulte. [Los alcances de los recursos de SMART on FHIR son: HealthLake](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest)
# Los osciloscopios SMART on FHIR OAuth 2.0 son compatibles con HealthLake
HealthLake usa OAuth 2.0 como protocolo de autorización. El uso de este protocolo en su servidor de autorización le permite definir HealthLake los permisos del almacén de datos (crear, leer, actualizar, eliminar y buscar) para los recursos del FHIR a los que tiene acceso una aplicación cliente.
El marco SMART on FHIR define un conjunto de ámbitos que se pueden solicitar al servidor de autorizaciones. Por ejemplo, una aplicación cliente que solo esté diseñada para permitir a los pacientes ver sus resultados de laboratorio o ver sus datos de contacto solo debería estar *autorizada* a solicitar `read` osciloscopios.
**nota**
HealthLake proporciona compatibilidad tanto con SMART en el FHIR V1 como en el V2, tal y como se describe a continuación. El SMART del 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)se establece en uno de los tres valores siguientes cuando se crea el banco de datos:
`SMART_ON_FHIR_V1`— Support solo para SMART en el FHIR V1, que incluye permisos `read` (lectura/búsqueda) y `write` (create/update/delete).
`SMART_ON_FHIR`— Soporte para SMART en FHIR V1 y V2, que incluye `create``read`, `update``delete`, y `search` permisos.
`AWS_AUTH`— La estrategia de AWS HealthLake autorización predeterminada; no está asociada a SMART en el FHIR.
## Alcance de lanzamiento independiente
HealthLake admite el ámbito del modo de lanzamiento independiente. `launch/patient`
En el modo de inicio independiente, una aplicación cliente solicita acceso a los datos clínicos del paciente porque la aplicación cliente no conoce al usuario ni al paciente. Por lo tanto, la solicitud de autorización de la aplicación cliente solicita explícitamente que se devuelva la sonda del paciente. Tras una autenticación correcta, el servidor de autorización emite un token de acceso que contiene el osciloscopio de pacientes de lanzamiento solicitado. El contexto del paciente necesario se proporciona junto con el token de acceso en la respuesta del servidor de autorización.
**Alcances del modo de lanzamiento compatibles**
| Alcance | Description (Descripción) |
| --- | --- |
| `launch/patient` | Parámetro de una solicitud de autorización OAuth 2.0 que solicita que se devuelvan los datos del paciente en la respuesta de autorización. |
## Los alcances de los recursos de SMART on FHIR son: HealthLake
HealthLake define tres niveles de SMART en los ámbitos de los recursos del FHIR.
+ `patient`los alcances permiten acceder a datos específicos sobre un solo paciente.
+ `user`los ámbitos otorgan acceso a datos específicos a los que puede acceder un usuario.
+ `system`los alcances permiten el acceso a todos los recursos del FHIR que se encuentran en el HealthLake almacén de datos.
En las siguientes secciones se muestra la sintaxis para construir los alcances de los recursos del FHIR mediante SMART en el FHIR V1 o SMART en el FHIR V2.
**nota**
La estrategia de autorización SMART on FHIR se establece cuando se crea el banco de datos. Para obtener más información, consulta [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) en la *AWS HealthLake Referencia de la API de *.
### Los osciloscopios SMART on FHIR V1 son compatibles con HealthLake
Cuando se utiliza SMART en el FHIR V1, la sintaxis general para construir los ámbitos de los recursos del FHIR es la siguiente. HealthLake **Para ver la ruta URL completa en el siguiente ejemplo, desplácese sobre el botón Copiar.**
```
('patient' | 'user' | 'system') '/' (fhir-resource | '*') '.' ('read' | 'write' | '*')
```
**Los ámbitos de autorización compatibles con SMART en la versión FHIR v1**
| Sintaxis del ámbito | Ejemplo de ámbito | Resultado |
| --- | --- | --- |
| `patient/(fhir-resource \| '*').('read' \| 'write' \| '*')` | patient/AllergyIntolerance.\$1 | La aplicación cliente para pacientes tiene acceso de lectura/escritura a nivel de instancia a todas las alergias registradas. |
| `user/(fhir-resource \| '*').('read' \| 'write' \| '*')` | user/Observation.read | La aplicación cliente de usuario tiene acceso a nivel de instancia read/write a todas las observaciones registradas. |
| system/('read' \$1 'write' \$1 \$1) | system/\$1.\$1 | La aplicación cliente del sistema tiene read/write acceso a todos los datos de los recursos del FHIR. |
### SMART en los osciloscopios FHIR V2 compatibles con HealthLake
Cuando se utiliza SMART en el FHIR V2, la sintaxis general para construir los alcances de los recursos del FHIR es la siguiente. HealthLake **Para ver la ruta URL completa en el siguiente ejemplo, desplácese sobre el botón Copiar.**
```
('patient' | 'user' | 'system') '/' (fhir-resource | '*') '.' ('c' | 'r' | 'u' | 'd' | 's')
```
**nota**
Para usar SMART en el FHIR V2, debe pasar el valor [https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#permissions](https://hl7.org/fhir/smart-app-launch/STU2/conformance.html#permissions)a la `capabilities` cadena de metadatos, que forma parte del tipo de [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)datos.
HealthLake admite ámbitos granulares. Para obtener más información, consulte los [ámbitos granulares compatibles](https://hl7.org/fhir/us/core/scopes.html#the-following-granular-scopes-shall-be-supported) en la Guía de implementación *básica del FHIR para EE. UU*.
**Los ámbitos de autorización compatibles con SMART on FHIR V2**
| Sintaxis del ámbito | Ejemplo de ámbito V1 | Resultado |
| --- | --- | --- |
| `patient/Observation.rs` | user/Observation.read | Permiso para leer y buscar el Observation recurso del paciente actual. |
| `system/*.cruds` | system/\$1.\$1 | La aplicación cliente del sistema tiene create/read/update/delete/search acceso total a todos los datos de los recursos del FHIR. |
# Validación de token mediante AWS Lambda
Al crear un almacén de datos habilitado para HealthLake SMART en el FHIR, debe proporcionar el ARN de AWS Lambda la función en `CreateFHIRDatastore` la solicitud. El ARN de la función Lambda se especifica en el `IdentityProviderConfiguration` objeto mediante el parámetro. `IdpLambdaArn`
Debe crear la función Lambda antes de crear su banco de datos habilitado para SMART on FHIR. Una vez creado el banco de datos, no se puede cambiar el ARN de Lambda. Para ver el ARN de Lambda que especificó al crear el banco de datos, utilice la acción de la API. `DescribeFHIRDatastore`
**Para que una solicitud REST de FHIR tenga éxito en un almacén de datos habilitado para SMART on FHIR, la función Lambda debe hacer lo siguiente:**
+ Devuelve una respuesta en menos de 1 segundo al punto final del almacén de HealthLake datos.
+ Decodifique el token de acceso proporcionado en el encabezado de autorización de la solicitud de API REST enviada por la aplicación cliente.
+ Asigne una función de servicio de IAM que tenga permisos suficientes para llevar a cabo la solicitud de la API REST del FHIR.
+ Para completar una solicitud de la API REST del FHIR, se requieren las siguientes afirmaciones. Para obtener más información, consulte [Reclamaciones requeridas](reference-smart-on-fhir-authentication.md#server-response).
+ `nbf`
+ `exp`
+ `isAuthorized`
+ `aud`
+ `scope`
Al trabajar con Lambda, además de la función Lambda, debe crear un rol de ejecución y una política basada en recursos. La función de ejecución de una función de Lambda es una función de IAM que otorga a la función permiso para acceder a los servicios y recursos de AWS necesarios en tiempo de ejecución. La política basada en recursos que proporcione debe permitir HealthLake invocar su función en su nombre.
En las secciones de este tema se describe un ejemplo de solicitud de una aplicación cliente y una respuesta decodificada, los pasos necesarios para crear una función AWS Lambda y cómo crear una política basada en recursos que se pueda asumir. HealthLake
+ [Parte 1: Creación de una función Lambda](#smart-on-fhir-lambda-create)
+ [Parte 2: Crear un rol HealthLake de servicio utilizado por la función AWS Lambda](#smart-on-fhir-lambda-service-role)
+ [Parte 3: Actualización del rol de ejecución de la función Lambda](#smart-on-fhir-lambda-service-role-execution-role)
+ [Parte 4: Añadir una política de recursos a la función Lambda](#smart-on-fhir-lambda-invoke-healthlake)
+ [Parte 5: Aprovisionamiento simultáneo para su función Lambda](#smart-on-fhir-lambda-function-scaling)
## Creación de una AWS función Lambda
La función Lambda creada en este tema se activa cuando HealthLake recibe una solicitud a un almacén de datos habilitado para SMART en FHIR. La solicitud de la aplicación cliente contiene una llamada a la API REST y un encabezado de autorización que contiene un token de acceso.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
Authorization: Bearer i8hweunweunweofiwweoijewiwe
```
El ejemplo de la función Lambda de este tema se utiliza AWS Secrets Manager para ocultar las credenciales relacionadas con el servidor de autorización. Recomendamos encarecidamente no proporcionar los detalles de inicio de sesión del servidor de autorización directamente en una función Lambda.
**Example validar una solicitud REST del FHIR que contenga un token portador de autorización**
La función Lambda de ejemplo muestra cómo validar una solicitud REST de FHIR enviada a un almacén de datos SMART en FHIR habilitado. Para ver step-by-steps instrucciones sobre cómo implementar esta función Lambda, consulte. [Creación de una función Lambda mediante el Consola de administración de AWS](#create-lambda-console)
Si la solicitud de la API REST de FHIR no contiene un punto final de almacén de datos, un token de acceso y una operación REST válidos, la función Lambda fallará. Para obtener más información sobre los elementos del servidor de autorización necesarios, consulte. [Reclamaciones requeridas](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()
```
### Creación de una función Lambda mediante el Consola de administración de AWS
El siguiente procedimiento supone que ya ha creado la función de servicio que desea asumir HealthLake al gestionar una solicitud de la API REST del FHIR en un almacén de datos habilitado para SMART on FHIR. Si no ha creado el rol de servicio, aún puede crear la función Lambda. Debe añadir el ARN del rol de servicio para que la función Lambda funcione. Para obtener más información sobre cómo crear un rol de servicio y especificarlo en la función Lambda, consulte [Crear un rol HealthLake de servicio para usarlo en la función AWS Lambda utilizada para decodificar un JWT](#smart-on-fhir-lambda-service-role)
**Para crear una función Lambda ()Consola de administración de AWS**
1. Abra la página de [Functions](https://console.aws.amazon.com/lambda/home/functions) (Funciones) en la consola de Lambda.
1. Seleccione **Creación de función**.
1. Seleccione **Crear desde cero**.
1. En **Información básica**, introduzca un **nombre de función**. En **Tiempo de ejecución**, elija un tiempo de ejecución basado en Python.
1. En **Execution role** (Rol de ejecución), elija **Create a new role with basic Lambda permissions** (Crear un nuevo rol con permisos básicos de Lambda).
Lambda crea un [rol de ejecución](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) que otorga a la función permiso para cargar registros en Amazon. CloudWatch La función Lambda asume la función de ejecución cuando se invoca la función y la utiliza para crear credenciales para el SDK. AWS
1. Seleccione la pestaña **Código** y añada la función Lambda de ejemplo.
Si aún no ha creado el rol de servicio que va a utilizar la función Lambda, tendrá que crearlo antes de que funcione la función Lambda de ejemplo. Para obtener más información sobre la creación de un rol de servicio para la función Lambda, consulte. [Crear un rol HealthLake de servicio para usarlo en la función AWS Lambda utilizada para decodificar un 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()
```
### Modificación del rol de ejecución de una función Lambda
Tras crear la función Lambda, debe actualizar el rol de ejecución para incluir los permisos necesarios para llamar a Secrets Manager. En Secrets Manager, cada secreto que crees tiene un ARN. Para aplicar el mínimo de privilegios, la función de ejecución solo debe tener acceso a los recursos necesarios para que se ejecute la función Lambda.
Puede modificar la función de ejecución de una función de Lambda buscándola en la consola de IAM o seleccionando **Configuración** en la consola de Lambda. Para obtener más información sobre la administración de su función de ejecución de funciones de Lambda, consulte. [Rol de ejecución de Lambda](#smart-on-fhir-lambda-service-role-execution-role)
**Example Función de ejecución de la función Lambda que otorga acceso a `GetSecretValue`**
Al añadir la acción de IAM `GetSecretValue` a la función de ejecución, se otorga el permiso necesario para que funcione la función Lambda de muestra.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secret-name-DKodTA"
}
]
}
```
En este punto, ha creado una función Lambda que se puede utilizar para validar el token de acceso proporcionado como parte de la solicitud REST de FHIR enviada a su almacén de datos SMART on FHIR habilitado.
## Crear un rol HealthLake de servicio para usarlo en la función AWS Lambda utilizada para decodificar un JWT
**Perfil: administrador de IAM**
Un usuario que puede añadir o eliminar políticas de IAM y crear nuevas identidades de IAM.
**Rol de servicio**
Un rol de servicio es un [rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que asume un servicio para realizar acciones en su nombre. Un administrador de IAM puede crear, modificar y eliminar un rol de servicio desde IAM. Para obtener más información, consulte [Crear un rol para delegar permisos a un Servicio de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) en la *Guía del usuario de IAM*.
Una vez decodificado el token web JSON (JWT), Lambda también necesita devolver un ARN de rol de IAM. Esta función debe tener los permisos necesarios para llevar a cabo la solicitud de la API REST o fallará por falta de permisos.
Al configurar una política personalizada mediante IAM, lo mejor es conceder los permisos mínimos necesarios. *Para obtener más información, consulte [Aplicar permisos con privilegios mínimos en la Guía](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) del usuario de IAM.*
La creación HealthLake de un rol de servicio para designarlo en la función Lambda de autorización requiere dos pasos.
+ En primer lugar, debe crear una política de IAM. La política debe especificar el acceso a los recursos del FHIR para los que ha proporcionado ámbitos en el servidor de autorización.
+ En segundo lugar, debe crear el rol de servicio. Al crear el rol, designa una relación de confianza y adjunta la política que creó en el primer paso. La relación de confianza se designa HealthLake como principal del servicio. Debe especificar un ARN de almacén de HealthLake datos y un ID de AWS cuenta en este paso.
### Crear una nueva política de IAM
Los ámbitos que defina en su servidor de autorización determinan a qué recursos del FHIR tiene acceso un usuario autenticado en un almacén de datos. HealthLake
La política de IAM que cree se puede personalizar para que coincida con los ámbitos que haya definido.
Se pueden definir las siguientes acciones en el `Action` elemento de una declaración de política de IAM. Para cada uno de `Action` los elementos de la tabla, puede definir un`Resource types`. En HealthLake un banco de datos, es el único tipo de recurso admitido que se puede definir en el `Resource` elemento de una declaración de política de permisos de IAM.
Los recursos individuales del FHIR no son un recurso que se pueda definir como un elemento de una política de permisos de la IAM.
**Acciones definidas por HealthLake**
| Acciones | Descripción | Nivel de acceso | Tipo de recurso (obligatorio) |
| --- | --- | --- | --- |
| CreateResource | Otorga permiso para crear un recurso | Escritura | ARN del almacén de datos: arn:aws:healthlake: :datastore/fhir/ your-region 111122223333 your-datastore-id |
| DeleteResource | Otorga permiso para eliminar un recurso | Escritura | ARN del almacén de datos: arn:aws:healthlake: :datastore/fhir/ your-region 111122223333 your-datastore-id |
| ReadResource | Otorga permiso para leer el recurso | Lectura | ARN del almacén de datos: arn:aws:healthlake: :datastore/fhir/ your-region 111122223333 your-datastore-id |
| SearchWithGet | Otorga permiso para buscar recursos con el método GET | Lectura | ARN del almacén de datos: arn:aws:healthlake: :datastore/fhir/ your-region 111122223333 your-datastore-id |
| SearchWithPost | Otorga permiso para buscar recursos con el método POST | Lectura | ARN del almacén de datos: arn:aws:healthlake: :datastore/fhir/ your-region 111122223333 your-datastore-id |
| Inicio FHIRExport JobWithPost | Otorga permiso para iniciar un trabajo de exportación del FHIR con GET | Escritura | ARN del almacén de datos: arn:aws:healthlake: :datastore/fhir/ your-region 111122223333 your-datastore-id |
| UpdateResource | Otorga permiso para actualizar el recurso | Escritura | ARN del almacén de datos: arn:aws:healthlake: :datastore/fhir/ your-region 111122223333 your-datastore-id |
Para empezar, puede utilizar. `AmazonHealthLakeFullAccess` Esta política permitiría leer, escribir, buscar y exportar todos los recursos del FHIR que se encuentren en un almacén de datos. Para conceder permisos de solo lectura en un almacén de datos, utilice. `AmazonHealthLakeReadOnlyAccess`
*Para obtener más información sobre cómo crear una política personalizada mediante el Consola de administración de AWS, o el IAM AWS CLI SDKs, consulte [Creación de políticas de IAM en la Guía del usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html).*
### Crear un rol de servicio para HealthLake (consola de IAM)
Utilice este procedimiento para crear un rol de servicio. Al crear un servicio, también tendrá que designar una política de IAM.
**Para crear el rol de servicio para HealthLake (consola de IAM)**
1. Inicie sesión en la consola de IAM Consola de administración de AWS y ábrala en. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. En el panel de navegación de la consola de IAM, elija **Roles**.
1. A continuación, elija **Create role** (Crear rol).
1. En la página **Seleccionar entidad de confianza**, elija **Política de confianza personalizada**.
1. A continuación, en **Política de confianza personalizada**, actualice la política de ejemplo de la siguiente manera. **your-account-id**Sustitúyalo por su número de cuenta y añada el ARN del banco de datos que desee utilizar en sus trabajos de importación o exportación.
------
#### [ 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. A continuación, elija **Siguiente**.
1. En la página **Agregar permisos**, elija la política que desee que asuma el HealthLake servicio. Para encontrar tu política, búscala en **Políticas de permisos**.
1. A continuación, selecciona **Adjuntar política**.
1. A continuación, en la página **Nombre, revisión y creación**, situada en **Nombre del rol**, introduzca un nombre.
1. (Opcional) A continuación, en **Descripción**, añade una breve descripción de tu función.
1. De ser posible, escriba un nombre o sufijo de nombre para el rol, que pueda ayudarle a identificar su finalidad. Los nombres de rol deben ser únicos en su Cuenta de AWS. No se distingue por caso. Por ejemplo, no puede crear funciones denominado tanto **PRODROLE** como **prodrole**. Dado que varias entidades pueden hacer referencia al rol, no puede editar el nombre del rol después de crearlo.
1. Revisa los detalles del rol y, a continuación, selecciona **Crear rol**.
Para obtener información sobre cómo especificar el ARN del rol en la función Lambda de ejemplo, consulte. [Creación de una AWS función Lambda](#smart-on-fhir-lambda-create)
## Rol de ejecución de Lambda
La función de ejecución de una función Lambda es una función de IAM que concede a la función permiso para acceder a los AWS servicios y recursos. Esta página proporciona información sobre cómo crear, ver y administrar el rol de ejecución de una función de Lambda.
De forma predeterminada, Lambda crea un rol de ejecución con permisos mínimos al crear una nueva función de Lambda mediante. Consola de administración de AWS Para gestionar los permisos concedidos en la función de ejecución, consulte [Creación de una función de ejecución en la consola de IAM](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html#permissions-executionrole-console) en la Guía para desarrolladores de *Lambda*.
La función Lambda de ejemplo que se proporciona en este tema usa Secrets Manager para ocultar las credenciales del servidor de autorización.
Al igual que con cualquier función de IAM que cree, es importante seguir las mejores prácticas con privilegios mínimos. Durante la fase de desarrollo, a veces es posible que concedas permisos más allá de lo necesario. Antes de publicar la función en el entorno de producción, la práctica recomendada consiste en ajustar la política para incluir solo los permisos necesarios. Para obtener más información, consulte [Aplicar los privilegios mínimos en la Guía](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) del usuario de *IAM*.
## Permita HealthLake activar su función Lambda
Para HealthLake poder invocar la función Lambda en su nombre, debe hacer lo siguiente:
+ Debe establecer un `IdpLambdaArn` valor igual al ARN de la función Lambda que desee HealthLake invocar en la solicitud. `CreateFHIRDatastore`
+ Necesita una política basada en recursos que le permita HealthLake invocar la función Lambda en su nombre.
Cuando HealthLake recibe una solicitud de la API REST de FHIR en un almacén de datos habilitado para SMART o FHIR, necesita permisos para invocar en su nombre la función Lambda especificada en la creación del almacén de datos. Para conceder el HealthLake acceso, utilizará una política basada en los recursos. *Para obtener más información sobre cómo crear una política basada en recursos para una función de Lambda, consulte [Permitir que un AWS servicio llame a una función de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke) en la Guía para desarrolladores.AWS Lambda *
## Aprovisionamiento simultáneo para su función Lambda
**importante**
HealthLake requiere que el tiempo máximo de ejecución de la función Lambda sea inferior a un segundo (1000 milisegundos).
Si la función Lambda supera el límite de tiempo de ejecución, se produce una TimeOutexcepción.
Para evitar esta excepción, se recomienda configurar la simultaneidad aprovisionada. Mediante la asignación de la simultaneidad aprovisionada antes de un aumento en las invocaciones, puede asegurarse de que todas las solicitudes se atiendan mediante instancias inicializadas con una latencia baja. *Para obtener más información sobre la configuración de la simultaneidad aprovisionada, consulte [Configuración de la simultaneidad aprovisionada en la Guía para desarrolladores](https://docs.aws.amazon.com/ambda/latest/dg/provisioned-concurrency.html) de Lambda*
Para ver el tiempo medio de ejecución de la función Lambda en la actualidad, utilice la página de **supervisión** de la función Lambda en la consola de Lambda. De forma predeterminada, la consola Lambda proporciona un gráfico de **duración** que muestra la cantidad media, mínima y máxima de tiempo que el código de función dedica a procesar un evento. *Para obtener más información sobre la supervisión de las funciones de Lambda, consulte [Supervisión de las funciones en la consola de Lambda en la Guía para desarrolladores de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-access-metrics.html#monitoring-console-graph-types).*
*Si ya ha aprovisionado la simultaneidad para la función de Lambda y desea supervisarla, consulte [Supervisión de la simultaneidad](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-concurrency.html) en la Guía para desarrolladores de Lambda.*
# Uso de una autorización detallada con un almacén de datos habilitado para SMART on FHIR HealthLake
[Los ámbitos](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest) por sí solos no proporcionan la especificidad necesaria sobre los datos a los que el solicitante está autorizado a acceder en un almacén de datos. El uso de una autorización detallada permite un mayor nivel de especificidad a la hora de conceder acceso a un almacén de datos compatible con SMART en el FHIR. HealthLake Para utilizar una autorización detallada, establezca un `FineGrainedAuthorizationEnabled` valor igual a `True` en el parámetro de su solicitud. `IdentityProviderConfiguration` `CreateFHIRDatastore`
Si has habilitado la autorización detallada, tu servidor de autorización devuelve un `fhirUser` ámbito junto con el `id_token` token de acceso. Esto permite que la aplicación cliente recupere la información sobre el usuario. La aplicación cliente debe tratar la `fhirUser` reclamación como el URI de un recurso del FHIR que represente al usuario actual. Este valor puede ser `Patient`, `Practitioner` o `RelatedPerson`. La respuesta del servidor de autorización también incluye un `user/` ámbito que define a qué datos puede acceder el usuario. Utiliza la sintaxis definida para los ámbitos relacionados con los ámbitos específicos de los recursos del FHIR:
```
user/(fhir-resource | '*').('read' | 'write' | '*')
```
Los siguientes son ejemplos de cómo se puede utilizar la autorización detallada para especificar con más detalle los tipos de recursos del FHIR relacionados con el acceso a los datos.
+ Cuándo `fhirUser` es una autorización detallada`Practitioner`, determina el conjunto de pacientes a los que puede acceder el usuario. Solo `fhirUser` se permite el acceso a aquellos pacientes en los que el paciente tenga referencias `fhirUser` como médico generalista.
```
Patient.generalPractitioner : [{Reference(Practitioner)}]
```
+ Cuando `fhirUser` es un `Patient` o `RelatedPerson` y el paciente al que se hace referencia en la solicitud es diferente del `fhirUser` indicado, la autorización detallada determina el acceso del paciente `fhirUser` solicitado. Se permite el acceso cuando existe una relación especificada en el recurso solicitado. `Patient`
```
Patient.link.other : {Reference(Patient|RelatedPerson)}
```
# Obtención del documento de descubrimiento SMART on FHIR
SMART define un documento de descubrimiento que permite a los clientes conocer el punto final de autorización URLs y cuenta con los soportes de un almacén de HealthLake datos. Esta información ayuda a los clientes a dirigir las solicitudes de autorización al punto final correcto y a crear las solicitudes de autorización compatibles con el almacén de HealthLake datos.
Para que una aplicación cliente pueda realizar correctamente una solicitud REST del FHIR HealthLake, debe reunir los requisitos de autorización definidos por el banco de HealthLake datos. *No* se requiere un token de portador (autorización) para que esta solicitud se realice correctamente.
**Para solicitar el documento de descubrimiento de un almacén de HealthLake datos**
1. Recopile HealthLake `region` y `datastoreId` valore. Para obtener más información, consulte [Obtención de propiedades de los almacenes de datos](managing-data-stores-describe.md).
1. Cree una URL para la solicitud utilizando los valores recopilados para HealthLake `region` y`datastoreId`. `/.well-known/smart-configuration`Añádala al punto final de la URL. Para ver la ruta URL completa en el siguiente ejemplo, desplázate sobre el botón **Copiar**.
```
https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/.well-known/smart-configuration
```
1. Envíe la solicitud utilizando `GET` el protocolo de [AWS firma Signature versión 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html). Para ver el ejemplo completo, desplázate sobre el botón **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'
```
------
El documento de descubrimiento del banco de HealthLake datos aparece como un blob JSON, donde puede encontrar el `authorization_endpoint` y el almacén de datos`token_endpoint`, junto con las especificaciones y las capacidades definidas para el banco de datos.
```
{
"authorization_endpoint": "https://oidc.example.com/authorize",
"token_endpoint": "https://oidc.example.com/oauth/token",
"capabilities": [
"launch-ehr",
"client-public"
]
}
```
`authorization_endpoint`Tanto el como el `token_endpoint` son necesarios para lanzar una aplicación cliente.
+ **Punto final de autorización**: la URL necesaria para autorizar una aplicación cliente o un usuario.
+ **Punto final del token**: punto final del servidor de autorización con el que la aplicación cliente se comunica.
# Realizar una solicitud a la API REST de FHIR en un almacén de datos habilitado para SMART HealthLake
Puede realizar solicitudes a la API REST del FHIR en un almacén de datos habilitado para SMART o FHIR. HealthLake El siguiente ejemplo muestra una solicitud de una aplicación cliente que contiene un JWT en el encabezado de autorización y cómo Lambda debe decodificar la respuesta. Una vez autorizada y autenticada la solicitud de la aplicación cliente, debe recibir un token portador del servidor de autorización. Utilice el token portador del encabezado de autorización cuando envíe una solicitud de API REST del FHIR a un almacén de datos habilitado para SMART o FHIR. HealthLake
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/[ID]
Authorization: Bearer auth-server-provided-bearer-token
```
Como se encontró un token portador en el encabezado de autorización y no se detectó ninguna identidad de AWS IAM, se HealthLake invoca la función Lambda especificada cuando se creó el almacén de datos habilitado para SMART on FHIR. HealthLake Cuando la función Lambda decodifica correctamente el token, se envía el siguiente ejemplo de respuesta a. 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
}
```
# Soporte FHIR R4 para AWS HealthLake
AWS HealthLake es compatible con la especificación R4 del FHIR para el intercambio de datos de salud. En las siguientes secciones se proporciona información complementaria sobre cómo se HealthLake utiliza la especificación R4 del FHIR para ayudarle a [gestionar](managing-fhir-resources.md) y [buscar](searching-fhir-resources.md) los recursos del FHIR en su HealthLake almacén de datos mediante el FHIR R4. RESTful APIs
**Topics**
+ [Declaración de capacidad](reference-fhir-capability-statement.md)
+ [Validaciones de perfil](reference-fhir-profile-validations.md)
+ [Tipos de recurso](reference-fhir-resource-types.md)
+ [Parámetros de búsqueda](reference-fhir-search-parameters.md)
+ [\$1 Operaciones](reference-fhir-operations.md)
# Declaración de capacidad del FHIR R4 para AWS HealthLake
Para encontrar las capacidades (comportamientos) relacionadas con el FHIR de un banco de HealthLake datos activo, debe recuperar su declaración de capacidad. La declaración de capacidad se utiliza como una declaración de la funcionalidad real del servidor o una declaración de la implementación del servidor requerida o deseada. La [https://hl7.org/fhir/R4/http.html#capabilities](https://hl7.org/fhir/R4/http.html#capabilities)interacción del FHIR recupera información sobre las capacidades del almacén de HealthLake datos y las partes de la especificación del FHIR compatibles. HealthLake valida los tipos de recursos del FHIR según el recurso R4 del FHIR. [https://hl7.org/fhir/R4/structuredefinition.html](https://hl7.org/fhir/R4/structuredefinition.html)
**Para obtener la declaración de capacidad de un banco de datos HealthLake**
1. Recopile HealthLake `region` y `datastoreId` valore. Para obtener más información, consulte [Obtención de propiedades de los almacenes de datos](managing-data-stores-describe.md).
1. Cree una URL para la solicitud utilizando los valores recopilados para HealthLake `region` y`datastoreId`. Incluye también el `metadata` elemento FHIR en la URL. Para ver la ruta URL completa en el siguiente ejemplo, desplázate sobre el botón **Copiar**.
```
https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/metadata
```
1. Envíe la solicitud . La `capabilities` interacción FHIR utiliza una `GET` solicitud con el protocolo de [AWS firma Signature, versión 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html). En el siguiente `curl` ejemplo, se obtiene la declaración de capacidad del almacén de HealthLake datos especificado por. `datastoreId` Para ver el ejemplo completo, desplácese sobre el botón **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'
```
------
Recibirá un código de respuesta `200` HTTP y la declaración de capacidad de su almacén HealthLake de datos. Para obtener más información, consulte [https://hl7.org/fhir/R4/capabilitystatement.html](https://hl7.org/fhir/R4/capabilitystatement.html)la documentación del **FHIR R4**.
# Validaciones de perfil FHIR para HealthLake
AWS HealthLake es compatible con la especificación básica del [FHIR R4](https://hl7.org/fhir/R4). En la especificación básica del FHIR R4 se incluyen los perfiles FHIR. Los perfiles se utilizan en un tipo de recurso FHIR para definir una definición de tipo de recurso más específica mediante and/or extensiones de restricciones del tipo de recurso base. Por ejemplo, un perfil del FHIR puede identificar campos obligatorios, como extensiones y conjuntos de valores. Un recurso puede admitir varios perfiles. Todos los almacenes HealthLake de datos admiten el uso de perfiles FHIR.
**nota**
*No* es necesario añadir un perfil FHIR al añadir datos a un banco de HealthLake datos. Si no se especifica un perfil del FHIR al añadir o actualizar un recurso, el recurso se valida únicamente con el esquema R4 del FHIR base.
Los perfiles del FHIR, a los que se ajustan los recursos del FHIR, se incluyen en los recursos antes de importarlos. HealthLake Por lo tanto, los perfiles del FHIR se validan durante la importación HealthLake .
Los perfiles del FHIR se especifican en una guía de implementación. Una guía de implementación (IG) del FHIR es un conjunto de instrucciones que describen cómo utilizar el estándar del FHIR para un propósito específico. HealthLake valida los perfiles del FHIR definidos en las siguientes guías de implementación.
**Los perfiles del FHIR están respaldados por AWS HealthLake**
| Name | Versión | Guía de implementación | Funcionalidad | Este de EE. UU. (Ohio) | Este de EE. UU. (Norte de Virginia) | Oeste de EE. UU. (Oregón) | Asia-Pacífico (Mumbai) | Asia-Pacífico (Sídney) | Canada (Central) | Europa (Irlanda) | Europa (Londres) |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Núcleo estadounidense | 3.1.1 | [http://hl7.org/fhir/us/core/STU3.1.1/](http://hl7.org/fhir/us/core/STU3.1.1/) | Predeterminado | X | X | X | X | X | X | X | X |
| Núcleo estadounidense | 4.0.0 | [https://hl7.org/fhir/us/core/STU4/index.html](https://hl7.org/fhir/us/core/STU4/index.html) | compatible | X | X | X | X | X | X | X | X |
| Núcleo estadounidense | 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) | compatible | X | X | X | X | X | X | X | X |
| Núcleo estadounidense | 6.1.0 | [https://hl7.org/fhir/us/core/STU6.1/index.html](https://hl7.org/fhir/us/core/STU6.1/index.html) | compatible | X | X | X | X | X | X | X | X |
| Núcleo estadounidense | 7.0.0 | [https://hl7.org/fhir/us/core/STU7/](https://hl7.org/fhir/us/core/STU7/) | compatible | X | X | X | X | X | X | X | X |
| Núcleo británico | 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) | compatible | X | X | X | X | | | X | X |
| Botón azul CARIN | 1.1.0 | [http://hl7.org/fhir/us/carin-bb/STU1.1/](http://hl7.org/fhir/us/carin-bb/STU1.1/) | Predeterminado | X | X | X | X | X | X | X | X |
| Botón 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) | compatible | X | X | X | X | X | X | X | X |
| Da Vinci Payer Data Exchange | 1.0.0 | [https://hl7.org/fhir/us/davinci-pdex/](https://hl7.org/fhir/us/davinci-pdex/) | Predeterminado | X | X | X | X | X | X | X | X |
| Da Vinci Payer Data Exchange | 2.0.0, 2.1.0 | [https://hl7.org/fhir/us/davinci-pdex/history.html](https://hl7.org/fhir/us/davinci-pdex/history.html) | compatible | X | X | X | X | X | X | X | X |
| Intercambio de registros de salud Da Vinci (HRex) | 0.2.0 | [https://hl7.org/fhir/us/davinci-hrex/2020Sep/](https://hl7.org/fhir/us/davinci-hrex/2020Sep/) | Predeterminado | X | X | X | X | X | X | X | X |
| DaVinci Plan PDEX: Red | 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/) | Predeterminado | X | X | X | X | X | X | X | X |
| DaVinci Plan 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/) | compatible | X | X | X | X | X | X | X | X |
| DaVinci Formulario de medicamentos de EE. UU. Payer Data Exchange (PDex) | 1.1.0 | [https://hl7.org/fhir/us/davinci-drug-formulary/STU1.1/](https://hl7.org/fhir/us/davinci-drug-formulary/STU1.1/) | Predeterminado | X | X | X | X | X | X | X | X |
| DaVinci Formulario de medicamentos de EE. UU. Payer Data Exchange (PDex) | 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) | compatible | X | X | X | X | X | X | X | X |
| Intercambio de datos 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) | Predeterminado | X | X | X | X | X | X | X | X |
| Da Vinci Prior Authorization Support (PAS) FHIR IG | 2.1.0 | [https://hl7.org/fhir/us/davinci-pas/](https://hl7.org/fhir/us/davinci-pas/) | Predeterminado | X | X | X | X | X | X | X | X |
| Guía de implementación de HEDIS® del NCQA | 0.3.1 | [https://www.ncqa.org/resources/hedis-ig-resource-page/](https://www.ncqa.org/resources/hedis-ig-resource-page/) | Predeterminado | X | X | X | X | | | X | X |
| Resumen de pacientes internacionales (IPS) | Votación 2.0.0 | [https://hl7.org/fhir/uv/ips/2024Sep/](https://hl7.org/fhir/uv/ips/2024Sep/) | Predeterminado | X | X | X | X | X | X | X | X |
| Medida de calidad | 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) | Predeterminado | X | X | X | X | | | X | X |
| Informes 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) | Predeterminado | X | X | X | X | | | X | X |
| Misión Digital Ayushman Bharat (ABDM) de la Autoridad Nacional de Salud | 2.0 | [https://www.nrces.in/ndhm/fhir/r4/index.html](https://www.nrces.in/ndhm/fhir/r4/index.html) | Predeterminado | X | X | X | X | | | X | X |
| CA Core\$1 | 1.1.0 | [https://simplifier.net/ca-core](https://simplifier.net/ca-core) | compatible | | | | | | X | | |
| CA: EEC Pan-Canadian eReferal-eConsult | 1.1.0 | [https://simplifier.net/CA-eReC/~introduction](https://simplifier.net/CA-eReC/~introduction) | compatible | | | | | | X | | |
| Resumen para pacientes, edición canadiense - (PS-CA) | 2.11 | [https://simplifier.net/PS-CA-R1/~introduction](https://simplifier.net/PS-CA-R1/~introduction) | compatible | | | | | | X | | |
| Repositorio de medicamentos de Ontario Digital Health | 4.0.3 | [https://simplifier.net/ca-on-dhdr-r4/~introduction](https://simplifier.net/ca-on-dhdr-r4/~introduction) | compatible | | | | | | X | | |
| Núcleo AU | 1.0.0 | [https://hl7.org.au/fhir/core/](https://hl7.org.au/fhir/core/) | compatible | | | | | X | | | |
| Gestión de la práctica de 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) | compatible | | | | | X | | | |
## Validar los perfiles del FHIR especificados en un recurso
Para validar un perfil del FHIR, agréguelo al `profile` elemento de los recursos individuales utilizando la URL del perfil designada en la guía de implementación.
Los perfiles del FHIR se validan cuando se agrega un nuevo recurso a su banco de datos. Para agregar un nuevo recurso, puede usar la operación de la `StartFHIRImportJob` API, realizar una `POST` solicitud para agregar un nuevo recurso o ` PUT ` actualizar un recurso existente.
**Example — Para ver a qué perfil del FHIR se hace referencia en un recurso**
La URL del perfil se añade al `profile` elemento del par `"meta" : "profile"` clave-valor. Este recurso se ha truncado para mayor claridad.
```
{
"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 — Cómo hacer referencia a un perfil FHIR compatible y no predeterminado**
Para realizar la validación con un perfil no predeterminado compatible (por ejemplo, CarinBB 1.0.0), añada la URL del perfil con la versión (separada por '\$1') y la URL del perfil base en el elemento. `meta.profile` Este recurso de ejemplo se ha truncado para mayor claridad.
```
{
"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 compatibles con FHIR R4 para HealthLake
En la siguiente tabla se enumeran los tipos de recursos del FHIR R4 compatibles con. AWS HealthLake Para obtener más información, consulte el [índice de recursos](https://hl7.org/fhir/R4/resourcelist.html) en la documentación del **FHIR R4**.
**Los tipos de recursos del FHIR R4 son compatibles con HealthLake**
| | | | |
| --- |--- |--- |--- |
| Cuenta | DetectedIssue | Factura | Profesional |
| ActivityDefinition | Dispositivo | Library | PractitionerRole |
| AdverseEvent | DeviceDefinition | Vinculación | Procedimiento |
| AllergyIntolerance | DeviceMetric | Enumeración | Procedencia |
| Cita | DeviceUseStatement | Ubicación | Cuestionario |
| AppointmentResponse | DeviceRequest | Medida | QuestionnaireResponse |
| AuditEvent - Ver nota | DiagnosticReport | MeasureReport | RelatedPerson |
| Binario | DocumentManifest | Multimedia | RequestGroup |
| BodyStructure | DocumentReference | ¿Medicamento | ResearchStudy |
| Paquete: consulte la nota | EffectEvidenceSynthesis | MedicationAdministration | ResearchSubject |
| CapabilityStatement | ¿Encuentro | MedicationDispense | RiskAssessment |
| CarePlan | Punto de conexión | MedicationKnowledge | RiskEvidenceSynthesis |
| CareTeam | EpisodeOfCare | MedicationRequest | Schedule |
| ChargeItem | EnrollmentRequest | MedicationStatement | ServiceRequest |
| ChargeItemDefinition | EnrollmentResponse | MessageHeader | Ranura |
| Reclamación | ExplanationOfBenefit | MolecularSequence | Ejemplar |
| ClaimResponse | FamilyMemberHistory | NutritionOrder | StructureDefinition |
| Comunicación | Indicador | Observación | StructureMap |
| CommunicationRequest | Objetivo | OperationOutcome - Ver nota | Substance |
| Composición | Group | Organización | SupplyDelivery |
| ConceptMap | GuidanceResponse | OrganizationAffiliation | SupplyRequest |
| Condición | HealthcareService | Parámetros: consulte la nota | Tarea |
| Consentimiento | ImagingStudy | Paciente | ValueSet |
| Contrato | Inmunización | PaymentNotice | VisionPrescription |
| Cobertura | ImmunizationEvaluation | PaymentReconciliation | VerificationResult - Ver nota |
| CoverageEligibilityRequest | ImmunizationRecommendation | Persona | |
| CoverageEligibilityResponse | InsurancePlan | PlanDefinition | |
**Especificaciones del FHIR y HealthLake**
No puede realizar `GET` ni `POST` solicitar el FHIR ni los tipos `OperationOutcome` de `Parameters` recursos.
**AuditEvent**— Se puede crear o leer un AuditEvent recurso, pero no se puede actualizar ni eliminar.
**Paquete**: hay varias formas de HealthLake gestionar las solicitudes de paquetes. Para obtener más información, consulte [Agrupación de recursos del FHIR](managing-fhir-resources-bundle.md).
**VerificationResult**— Este tipo de recurso solo es compatible con los almacenes de datos creados después del 9 de diciembre de 2023.
# Parámetros de búsqueda FHIR R4 para HealthLake
Utilice la [https://hl7.org/fhir/R4/http.html#search](https://hl7.org/fhir/R4/http.html#search)interacción del FHIR para buscar un conjunto de recursos del FHIR en un banco de HealthLake datos en función de algunos criterios de filtrado. La `search` interacción se puede realizar mediante una solicitud `GET` o`POST`. Para las búsquedas que incluyan información de identificación personal (PII) o información de salud protegida (PHI), se recomienda utilizar `POST` solicitudes, ya que la PII y la PHI se agregan como parte del cuerpo de la solicitud y se cifran durante el tránsito.
**nota**
La `search` interacción entre el FHIR que se describe en este capítulo se basa en el estándar R4 del HL7 FHIR para el intercambio de datos de atención médica. Como es una representación de un servicio de la HL7 FHIR, no se ofrece a través de y. AWS CLI AWS SDKs Para obtener más información, consulte la documentación de [https://hl7.org/fhir/R4/http.html#search](https://hl7.org/fhir/R4/http.html#search)la API **R4 RESTful del FHIR**.
También puede consultar almacenes HealthLake de datos con SQL mediante Amazon Athena. Para obtener más información, consulte Integración.
HealthLake admite el siguiente subconjunto de parámetros de búsqueda del FHIR R4. Para obtener más información, consulte [Parámetros de búsqueda FHIR R4 para HealthLake](#reference-fhir-search-parameters).
## Tipos de parámetros de búsqueda compatibles
En la siguiente tabla se muestran los tipos de parámetros de búsqueda admitidos en HealthLake.
**Tipos de parámetros de búsqueda compatibles**
| Parámetro de búsqueda | Description (Descripción) |
| --- | --- |
| \$1id | ID del recurso (no es una URL completa) |
| \$1Última actualización | Fecha de la última actualización. El servidor tiene discreción en cuanto a la precisión de los límites. |
| \$1tag | Busca por etiqueta de recurso. |
| \$1perfil | Busca todos los recursos etiquetados con un perfil. |
| \$1seguridad | Busque en las etiquetas de seguridad aplicadas a este recurso. |
| \$1fuente | Busque de dónde proviene el recurso. |
| \$1texto | Busque en la narrativa del recurso. |
| createdAt | Busque en la extensión personalizada CreatedAt. |
**nota**
Los siguientes parámetros de búsqueda solo se admiten en los almacenes de datos creados después del 9 de diciembre de 2023: \$1security, \$1source, \$1text, CreatedAt.
En la siguiente tabla se muestran ejemplos de cómo modificar las cadenas de consulta en función de los tipos de datos especificados para un tipo de recurso determinado. Para mayor claridad, los caracteres especiales de la columna de ejemplos no se han codificado. Para que la consulta se realice correctamente, asegúrese de que la cadena de consulta se haya codificado correctamente.
**Ejemplos de parámetros de búsqueda**
| Tipos de parámetros de búsqueda | Details | Ejemplos |
| --- | --- | --- |
| Número | Busca un valor numérico en un recurso específico. Se observan cifras significativas. El número de dígitos significativos es específico por valor de parámetro de búsqueda, excluyendo los ceros iniciales. Se permiten prefijos de comparación. | `[parameter]=100` `[parameter]=1e2` `[parameter]=lt100` |
| Fecha/ DateTime | Busca una fecha u hora específica. El formato esperado es`yyyy-mm-ddThh:mm:ss[Z\|(+\|-)hh:mm]`, pero puede variar. Acepta los siguientes tipos de datos: `date``dateTime`,`instant`,`Period`, y`Timing`. Para obtener más información sobre el uso de estos tipos de datos en las búsquedas, consulta la [fecha](https://www.hl7.org/fhir/search.html#date) en la documentación de la ** RESTful API R4 del FHIR**. Se permiten los prefijos de comparación. | `[parameter]=eq2013-01-14` `[parameter]=gt2013-01-14T10:00` `[parameter]=ne2013-01-14` |
| Cadena | Busca una secuencia de caracteres distinguiendo mayúsculas de minúsculas. Admite ambos `HumanName` `Address` tipos. Para obtener más información, consulte la entrada del [tipo de HumanName datos](https://www.hl7.org/fhir/datatypes.html#HumanName) y las entradas del [tipo de `Address` datos](https://www.hl7.org/fhir/datatypes.html#Address) en la documentación del **FHIR R4**. Se admite la búsqueda avanzada mediante `:text` modificadores. | `[base]/Patient?given=eve` `[base]/Patient?given:contains=eve` |
| Token | Busca una close-to-exact coincidencia con una cadena de caracteres, a menudo comparada con un par de valores de códigos médicos. La distinción entre mayúsculas y minúsculas está vinculada al sistema de código utilizado al crear una consulta. Las consultas basadas en subsuposiciones pueden ayudar a reducir los problemas relacionados con la distinción entre mayúsculas y minúsculas. Para mayor claridad, no se ha codificado. `\|` | `[parameter]=[system]\|[code]`: Aquí `[system]` se refiere a un sistema de codificación y `[code]` se refiere al valor de código que se encuentra dentro de ese sistema específico. `[parameter]=[code]`: En este caso, la entrada coincidirá con un código o un sistema. `[parameter]=\|[code]`: En este caso, la entrada coincidirá con un código y la propiedad del sistema no tiene ningún identificador. |
| Compuesto | Busca varios parámetros dentro de un único tipo de recurso mediante los modificadores `$` y la `,` operación. Se permiten los prefijos de comparación. | `/Patient?language=FR,NL&language=EN` `Observation?component-code-value-quantity=http://loinc.org\|8480-6$lt60` `[base]/Group?characteristic-value=gender$mixed` |
| Cantidad | Busca un número, un sistema y un código como valores. Se requiere un número, pero el sistema y el código son opcionales. Basado en el tipo de datos de cantidad. Para obtener más información, consulta la sección [Cantidad](https://www.hl7.org/fhir/datatypes.html#Quantity) en la documentación del **FHIR R4**. Utiliza la siguiente sintaxis asumida `[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` |
| Referencia | Busca referencias a otros recursos. | `[base]/Observation?subject=Patient/23` `test` |
| URI | Busca una cadena de caracteres que identifique de forma inequívoca un recurso concreto. | `[base]/ValueSet?url=http://acme.org/fhir/ValueSet/123` |
| Especial | Búsquedas basadas en extensiones de PNL médicas integradas. |
## Parámetros de búsqueda avanzada compatibles con HealthLake
HealthLake admite los siguientes parámetros de búsqueda avanzada.
| Name | Descripción | Ejemplo | Funcionalidad |
| --- | --- | --- | --- |
| \$1include | Se utiliza para solicitar que se devuelvan recursos adicionales en una solicitud de búsqueda. Devuelve los recursos a los que hace referencia la instancia de recurso de destino. | Encounter?\$1include=Encounter:subject | |
| \$1revinclude | Se utiliza para solicitar que se devuelvan recursos adicionales en una solicitud de búsqueda. Devuelve los recursos que hacen referencia a la instancia de recurso principal. | Patient?\$1id=patient-identifier&\$1revinclude=Encounter:patient | |
| \$1summary | El resumen se puede utilizar para solicitar un subconjunto del recurso. | Patient?\$1summary=text | Se admiten los siguientes parámetros de resumen:\$1summary=true,, \$1summary=false\$1summary=text,\$1summary=data. |
| \$1elements | Solicite que se devuelva un conjunto específico de elementos como parte de un recurso en los resultados de la búsqueda. | Patient?\$1elements=identifier,active,link | |
| \$1total | Devuelve el número de recursos que coinciden con los parámetros de búsqueda. | Patient?\$1total=accurate | Support\$1total=accurate,\$1total=none. |
| \$1sort | Indique el orden de clasificación de los resultados de búsqueda devueltos mediante una lista separada por comas. El - prefijo se puede usar para cualquier regla de clasificación de la lista separada por comas para indicar un orden descendente. | Observation?\$1sort=status,-date | Support ordenar por campos con tiposNumber, String, Quantity, Token, URI, Reference. La clasificación por solo Date se admite en los almacenes de datos creados después del 9 de diciembre de 2023. Support hasta 5 reglas de clasificación. |
| \$1count | Controle cuántos recursos se devuelven por página del paquete de búsqueda. | Patient?\$1count=100 | El tamaño máximo de página es 100. |
| chaining | Elementos de búsqueda de los recursos referenciados. .Dirige la búsqueda encadenada al elemento dentro del recurso referenciado. | DiagnosticReport?subject:Patient.name=peter | |
| reverse chaining (\$1has) | Busque un recurso en función de los elementos de los recursos que hacen referencia a él. | Patient?\$1has:Observation:patient:code=1234-5 | |
`_include`
Si se utiliza `_include` en una consulta de búsqueda, también se pueden obtener recursos adicionales específicos del FHIR. Se usa `_include` para incluir recursos que están enlazados hacia adelante.
**Example — Para localizar `_include` a los pacientes o al grupo de pacientes a los que se les ha diagnosticado tos**
Debería buscar en el tipo de `Condition` recurso especificando el código de diagnóstico de la tos y, a continuación, `_include` especificando que también desea que se devuelva ese diagnóstico. `subject` En el tipo `Condition` de recurso, `subject` se refiere al tipo de recurso del paciente o al tipo de recurso del grupo.
Para mayor claridad, los caracteres especiales del ejemplo no se han codificado. Para que la consulta se realice correctamente, asegúrese de que la cadena de consulta se haya codificado correctamente.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
Condition?code=49727002&_include=Condition:subject
```
`_include:iterate`Modificador
El `_include:iterate` modificador permite la inclusión recursiva de los recursos referenciados en dos niveles. Por ejemplo:
```
GET /ServiceRequest?identifier=025C0931195&_include=ServiceRequest:requester&_include:iterate=PractitionerRole:practitioner
```
devolverá el ServiceRequest, está asociado PractitionerRole (mediante la referencia del solicitante) y, a continuación, incluirá de forma recursiva al profesional al que hace referencia. PractitionerRole Este modificador está disponible para todos los tipos de recursos en. HealthLake
`_include=*`Modificador
El `_include=*` modificador es un comodín que incluye automáticamente todos los recursos a los que hacen referencia directamente los resultados de la búsqueda. Por ejemplo:
```
GET /ServiceRequest?specimen.accession=12345&_include=*
```
devolverá la coincidencia ServiceRequest junto con todos los recursos a los que haga referencia (como pacientes, profesionales, muestras, etc.) sin necesidad de especificar cada ruta de referencia de forma individual. Este modificador está disponible para todos los tipos de recursos en HealthLake.
`_revinclude`
Si se utiliza `_revinclude` en una consulta de búsqueda, también se pueden devolver recursos adicionales del FHIR especificados. `_revinclude`Utilícelo para incluir recursos que estén enlazados hacia atrás.
**Example — `_revinclude` Para incluir tipos de recursos relacionados con el encuentro y la observación vinculados a un paciente específico**
Para realizar esta búsqueda, primero debe definir a la persona `Patient` especificando su identificador en el parámetro `_id` de búsqueda. Luego, especificaría recursos adicionales del FHIR utilizando la estructura `Encounter:patient` y`Observation:patient`.
Para mayor claridad, los caracteres especiales del ejemplo no se han codificado. Para que la consulta se realice correctamente, asegúrese de que la cadena de consulta se haya codificado correctamente.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
Patient?_id=patient-identifier&_revinclude=Encounter:patient&_revinclude=Observation:patient
```
`_summary`
El uso `_summary` en una consulta de búsqueda permite al usuario solicitar un subconjunto del recurso FHIR. Puede contener uno de los siguientes valores:. `true, text, data, false` Cualquier otro valor se considerará inválido. Los recursos devueltos se marcarán con una `'SUBSETTED'` meta.tag para indicar que los recursos están incompletos.
+ `true`: Devuelve todos los elementos admitidos que estén marcados como «resumen» en la definición básica de los recursos.
+ `text`: Devuelve solo los elementos «texto», «identificador» y «meta» y solo los elementos obligatorios de nivel superior.
+ `data`: Devuelve todas las partes excepto el elemento «texto».
+ `false`: Devuelve todas las partes de los recursos
En una sola solicitud de búsqueda, `_summary=text` no se puede combinar con `_include` los parámetros `_revinclude` de búsqueda.
**Example — Obtenga el elemento «texto» de los recursos para pacientes en un almacén de datos.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_summary=text
```
`_elements`
El uso `_elements` en una consulta de búsqueda permite solicitar elementos de recursos específicos del FHIR. Los recursos devueltos se marcarán con una `'SUBSETTED'` etiqueta meta para indicar que los recursos están incompletos.
El `_elements` parámetro consiste en una lista de nombres de elementos base separados por comas, como los elementos definidos en el nivel raíz del recurso. Solo se devolverán los elementos que estén en la lista. Si los valores de los `_elements` parámetros contienen elementos no válidos, el servidor los ignorará y devolverá los elementos obligatorios y los elementos válidos.
`_elements`no se aplicará a los recursos incluidos (recursos devueltos cuyo modo de búsqueda es`include`).
En una sola solicitud de búsqueda, `_elements` no se puede combinar con los parámetros `_summary` de búsqueda.
**Example — Obtenga los elementos «identificadores», «activos» y «enlaces» de los recursos para pacientes en su almacén de HealthLake datos.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_elements=identifier,active,link
```
`_total`
Si se utiliza `_total` en una consulta de búsqueda, se devolverá el número de recursos que coinciden con los parámetros de búsqueda solicitados. HealthLake devolverá el número total de recursos coincidentes (recursos devueltos cuyo modo de búsqueda es`match`) en la respuesta `Bundle.total` de búsqueda.
`_total`admite los valores `accurate` de los `none` parámetros. `_total=estimate`no es compatible. Cualquier otro valor se considerará inválido. `_total`no se aplica a los recursos incluidos (recursos devueltos cuyo modo de búsqueda es`include`).
**Example — Obtenga el número total de recursos para pacientes en un almacén de datos:**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_total=accurate
```
`_sort`
Al `_sort` utilizarlos en la consulta de búsqueda, se ordenan los resultados en un orden específico. Los resultados se ordenan según la lista de reglas de clasificación separadas por comas en orden de prioridad. Las reglas de clasificación deben ser parámetros de búsqueda válidos. Los demás valores se considerarán inválidos.
En una sola solicitud de búsqueda, puede utilizar hasta 5 parámetros de búsqueda de clasificación. Si lo desea, puede utilizar un `-` prefijo para indicar el orden descendente. El servidor ordenará en orden ascendente de forma predeterminada.
Los tipos de parámetros de búsqueda de clasificación admitidos son:`Number, String, Date, Quantity, Token, URI, Reference`. Si un parámetro de búsqueda hace referencia a un elemento que está anidado, este parámetro de búsqueda no se admite para la ordenación. Por ejemplo, busque por «nombre» del tipo de recurso Paciente hace referencia a Patient.El elemento NAME con el tipo de HumanName datos se considera anidado. Por lo tanto, no se permite ordenar los recursos de los pacientes por «nombre».
**Example — Coloque los recursos para pacientes en un almacén de datos y ordénelos por fecha de nacimiento en orden ascendente:**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_sort=birthdate
```
`_count`
El parámetro `_count` se define como una instrucción al servidor sobre cuántos recursos deben devolverse en una sola página.
El tamaño máximo de página es 100. Los valores superiores a 100 no son válidos. `_count=0`no se admite.
**Example — Busque el recurso para pacientes y establezca el tamaño de la página de búsqueda en 25:**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_count=25
```
`Chaining and Reverse Chaining(_has)`
El encadenamiento y el encadenamiento inverso en el FHIR proporcionan una forma más eficiente y compacta de obtener datos interconectados, lo que reduce la necesidad de realizar múltiples consultas independientes y hace que la recuperación de datos sea más cómoda para los desarrolladores y los usuarios.
Si algún nivel de recursión arroja más de 100 resultados, HealthLake devolverá 4xx para evitar que el almacén de datos se sobrecargue y provoque múltiples paginaciones.
**Example — Encadenar: obtiene todo DiagnosticReport lo que hace referencia a un paciente cuyo nombre es peter.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/DiagnosticReport?subject:Patient.name=peter
```
**Example — Encadenamiento inverso: obtenga los recursos para pacientes, donde al menos una observación hace referencia al recurso para pacientes, donde la observación tiene el código 1234 y donde la observación hace referencia al recurso para pacientes en el parámetro de búsqueda de pacientes.**
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?_has:Observation:patient:code=1234
```
## Modificadores de búsqueda compatibles
Los modificadores de búsqueda se utilizan con campos basados en cadenas. Todos los modificadores de búsqueda HealthLake utilizan una lógica booleana. Por ejemplo, puede especificar `:contains` que un campo de cadena más grande incluya una cadena pequeña para que se incluya en los resultados de la búsqueda.
**Modificadores de búsqueda compatibles**
| Modificador de búsqueda | Tipo |
| --- | --- |
| :falta | Todos los parámetros excepto Composite |
| :exacto | Cadena |
| :contiene | Cadena |
| :no | Token |
| :texto | Token |
| :identificador | Referencia |
| :abajo | URI |
## Comparadores de búsqueda compatibles
Puede utilizar los comparadores de búsqueda para controlar la naturaleza de la coincidencia en una búsqueda. Puede utilizar los comparadores al buscar en los campos de número, fecha y cantidad. En la siguiente tabla se enumeran los comparadores de búsqueda y sus definiciones compatibles con. HealthLake
**Comparadores de búsqueda compatibles**
| Comparador de búsquedas | Description (Descripción) |
| --- | --- |
| eq | El valor del parámetro en el recurso es igual al valor proporcionado. |
| ne | El valor del parámetro en el recurso no es igual al valor proporcionado. |
| gt | El valor del parámetro en el recurso es mayor que el valor proporcionado. |
| lt | El valor del parámetro en el recurso es inferior al valor proporcionado. |
| Edad | El valor del parámetro del recurso es mayor o igual al valor proporcionado. |
| le | El valor del parámetro en el recurso es menor o igual al valor proporcionado. |
| sa | El valor del parámetro del recurso comienza después del valor proporcionado. |
| eb | El valor del parámetro en el recurso termina antes del valor proporcionado. |
## Los parámetros de búsqueda del FHIR no son compatibles con HealthLake
HealthLake admite todos los parámetros de búsqueda del FHIR, a excepción de los que se muestran en la siguiente tabla. Para obtener una lista completa de los parámetros de búsqueda del FHIR, consulte el registro de parámetros de [búsqueda del FHIR](https://hl7.org/fhir/R4/searchparameter-registry.html).
**Parámetros de búsqueda no compatibles**
| | |
| --- |--- |
| Composición del paquete | Ubicación: cerca |
| Identificador de paquete | C onsent-source-reference |
| Paquete: mensaje | Paciente contratado |
| Tipo de paquete | Contenido del recurso |
| Marca de tiempo del paquete | Consulta de recursos |
# FHIR R4 para `$operations` HealthLake
Las operaciones FHIR \$1 (también denominadas «operaciones en dólares») son funciones especiales del servidor que van más allá de las operaciones CRUD (`Create`,, `Read``Update`,`Delete`) estándar de la especificación FHIR. Estas operaciones se identifican con el prefijo «\$1» y permiten un procesamiento complejo, la transformación de datos y operaciones masivas que serían difíciles o ineficientes de realizar con llamadas a la API REST estándar. \$1 Las operaciones se pueden invocar a nivel del sistema, a nivel de tipo de recurso o en instancias de recursos específicas, lo que proporciona formas flexibles de interactuar con los datos del FHIR. AWS HealthLake admite varios FHIR`$operations`. Consulte cada una de las páginas individuales que aparecen a continuación para obtener más información.
**Topics**
+ [Funcionamiento FHIR R4 `$attribution-status` para HealthLake](reference-fhir-operations-attribution-status.md)
+ [Eliminar tipos de recursos con `$bulk-delete`](reference-fhir-operations-bulk-delete.md)
+ [`$bulk-member-match`operación para HealthLake](reference-fhir-operations-bulk-member-match.md)
+ [Funcionamiento FHIR R4 `$confirm-attribution-list` para HealthLake](reference-fhir-operations-confirm-attribution-list.md)
+ [Funcionamiento FHIR R4 `$davinci-data-export` para HealthLake](reference-fhir-operations-davinci-data-export.md)
+ [Generación de documentos clínicos con `$document`](reference-fhir-operations-document.md)
+ [Eliminar recursos de forma permanente con `$erase`](reference-fhir-operations-erase.md)
+ [Obtener datos de pacientes con `Patient/$everything`](reference-fhir-operations-everything.md)
+ [Recuperación de ValueSet códigos con `$expand`](reference-fhir-operations-expand.md)
+ [Exportación HealthLake de datos con FHIR `$export`](reference-fhir-operations-export.md)
+ [`$inquire`Operación FHIR para HealthLake](reference-fhir-operations-inquire.md)
+ [Recuperación de detalles conceptuales con `$lookup`](reference-fhir-operations-lookup.md)
+ [`$member-add`operación para HealthLake](reference-fhir-operations-member-add.md)
+ [`$member-match`operación para HealthLake](reference-fhir-operations-member-match.md)
+ [`$member-remove`operación para HealthLake](reference-fhir-operations-member-remove.md)
+ [Eliminar los recursos del compartimento de pacientes con `$purge`](reference-fhir-operations-purge.md)
+ [`$questionnaire-package`Operación FHIR para HealthLake](reference-fhir-operations-questionnaire-package.md)
+ [`$submit`Operación FHIR para HealthLake](reference-fhir-operations-submit.md)
+ [Validación de los recursos del FHIR con `$validate`](reference-fhir-operations-validate.md)
# Funcionamiento FHIR R4 `$attribution-status` para HealthLake
Recupera el estado de atribución de un miembro específico y devuelve un paquete que contiene todos los recursos de atribución relacionados con el paciente. Esta operación forma parte de la implementación de la Lista IG 2.1.0 de la [Lista de Atribución de Miembros (ATR) del FHIR](https://build.fhir.org/ig/HL7/davinci-atr/spec.html).
## Punto de conexión
```
POST [base]/Group/[id]/$attribution-status
```
## Parámetros de la solicitud
La operación acepta los siguientes parámetros opcionales:
| Parámetro | Tipo | Description (Descripción) |
| --- | --- | --- |
| memberId | Identificador | El MemberId del miembro para el que se solicita el estado de atribución |
| Referencia del paciente | Referencia | Referencia al recurso para pacientes en el sistema del productor |
**nota**
`patientReference`Se puede proporcionar uno `memberId` o ambos, o ambos con fines de validación.
## Solicitud de muestra
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "memberId",
"valueIdentifier": {
"system": "http://example.org",
"value": "MBR123456789"
}
},
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/patient-123",
"display": "John Doe"
}
}
]
}
```
## Respuesta
Devuelve un paquete que contiene recursos de atribución relacionados con el paciente:
| Recurso | Cardinalidad | Ubicación |
| --- | --- | --- |
| Paciente | 1..1 | Grupo, miembro, entidad |
| Cobertura | 0.1.. | Group.Member.Extension: referencia de cobertura |
| Organization/Practitioner/PractitionerRole | 0.1.. | group.member.extension: proveedor atribuido |
| ¿Algún recurso | 0.1.. | Group.Member.Extension: datos asociados |
### Respuesta de ejemplo
```
{
"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
}
}
]
}
```
## Gestión de errores
La operación gestiona las siguientes condiciones de error:
| Error | Estado HTTP | Description (Descripción) |
| --- | --- | --- |
| Solicitud de operación no válida | 400 | Estructura o parámetros de solicitud no conformes |
| No se encontró el recurso de grupo | 404 | El ID de grupo especificado no existe |
| No se encontró el recurso para pacientes | 404 | La referencia de paciente especificada no existe |
## Autorización y seguridad
Requisitos de SMART Scope
Los clientes deben tener los privilegios adecuados para leer los recursos del grupo y los recursos de atribución relacionados
Los mecanismos de autorización estándar del FHIR se aplican a todas las operaciones
# Eliminar tipos de recursos con `$bulk-delete`
AWS HealthLake admite la `$bulk-delete` operación, lo que permite eliminar todos los recursos de un tipo específico de un almacén de datos. Esta operación resulta especialmente útil cuando se necesita:
+ Realice auditorías y limpiezas estacionales
+ Gestione el ciclo de vida de los datos a escala
+ Elimine tipos de recursos específicos
+ Cumpla con las políticas de retención de datos
## De uso
La `$bulk-delete` operación se puede invocar mediante los métodos POST:
```
POST [base]/[ResourceType]/$bulk-delete?isHardDelete=false&deleteAuditEvent=true
```
## Parameters
| Parámetro | Tipo | Obligatorio/a | Predeterminado | Description (Descripción) |
| --- | --- | --- | --- | --- |
| isHardDelete | booleano | No | false | Si es verdadero, elimina permanentemente los recursos del almacenamiento |
| deleteAuditEvent | booleano | No | true | Si es verdadero, elimina los eventos de auditoría asociados |
| \$1since | cadena | No | Hora de creación del almacén de datos | Cuando se introduce, selecciona la hora límite de inicio para buscar los recursos en función de su hora de última modificación. No se puede usar ni al principio ni al final |
| start | cadena | No | Hora de creación del almacén de datos | Cuando se introduce, selecciona la hora límite para buscar los recursos en función de su hora de última modificación. Se puede usar con el final |
| end | cadena | No | Tiempo de presentación de trabajos | Cuando se introduce, selecciona la hora límite de finalización para buscar los recursos en función de su hora de última modificación |
## Ejemplos
**Solicitud de ejemplo**
```
POST [base]/Observation/$bulk-delete?isHardDelete=false
```
**Respuesta de ejemplo**
```
{
"jobId": "jobId",
"jobStatus": "SUBMITTED"
}
```
## Estado del trabajo
Para comprobar el estado de un trabajo de eliminación masiva:
```
GET [base]/$bulk-delete/[jobId]
```
La operación devuelve información sobre el estado del trabajo:
```
{
"datastoreId": "datastoreId",
"jobId": "jobId",
"status": "COMPLETED",
"submittedTime": "2025-10-09T15:09:51.336Z"
}
```
## Comportamiento
La `$bulk-delete` operación:
1. Procesa de forma asíncrona para gestionar grandes volúmenes de recursos
1. Mantiene las transacciones ACID para garantizar la integridad de los datos
1. Proporciona un seguimiento del estado de los trabajos con recuentos de eliminaciones de recursos
1. Soporta los modos de borrado suave y duro
1. Incluye un registro de auditoría completo de las actividades de eliminación
1. Permite la eliminación selectiva de versiones históricas y eventos de auditoría
## Registro de auditoría
La `$bulk-delete` operación se registra como Inicio FHIRBulk DeleteJob y Descripción FHIRBulk DeleteJob con información detallada sobre la operación.
## Limitaciones
+ Si `isHardDelete` se establece en True, los recursos eliminados de forma permanente no aparecerán en los resultados de búsqueda ni en `_history` las consultas.
+ Es posible que los recursos que se eliminen mediante esta operación no estén accesibles temporalmente durante el procesamiento
+ La medición del almacenamiento solo se ajusta en las versiones históricas; deleteVersionHistory =false no ajustará el almacenamiento en el almacén de datos
# `$bulk-member-match`operación para HealthLake
AWS HealthLake admite la `$bulk-member-match` operación de procesar las solicitudes de emparejamiento de varios miembros de forma asíncrona. Esta operación permite a las organizaciones de atención médica comparar de manera eficiente los identificadores únicos de cientos de miembros de diferentes sistemas de salud utilizando información demográfica y de cobertura en una sola solicitud masiva. [Esta capacidad es esencial para el intercambio de payer-to-payer datos a gran escala, las transiciones de miembros y los requisitos de conformidad con los CMS, y sigue la especificación de la FHIR.](https://build.fhir.org/ig/HL7/davinci-epdx/OperationDefinition-BulkMemberMatch.html)
**nota**
La `$bulk-member-match` operación se basa en una especificación subyacente del FHIR que actualmente se encuentra en fase experimental y está sujeta a cambios. A medida que la especificación evolucione, el comportamiento y la interfaz de esta API se actualizarán en consecuencia. Se recomienda a los desarrolladores que supervisen las notas de la HealthLake versión de AWS y las actualizaciones de las especificaciones del FHIR pertinentes para mantenerse informados de cualquier cambio que pueda afectar a sus integraciones.
Esta operación resulta especialmente útil cuando necesita:
+ Procese la comparación de miembros a gran escala durante los períodos de inscripción abierta
+ Facilite las transiciones masivas de miembros entre pagadores
+ Support con los requisitos de intercambio de datos de conformidad con los CMS a gran escala
+ Haga coincidir de manera eficiente las cohortes de miembros en todas las redes de atención médica
+ Minimice las llamadas a la API y mejore la eficiencia operativa en escenarios de coincidencia de gran volumen
## De uso
La `$bulk-member-match` operación es una operación asíncrona que se invoca en los recursos del grupo mediante el método POST:
```
POST [base]/Group/$bulk-member-match
```
Tras enviar una solicitud de coincidencia masiva, puedes sondear el estado del trabajo mediante:
```
GET [base]/$bulk-member-match-status/{jobId}
```
## Parámetros admitidos
HealthLake admite los siguientes `$bulk-member-match` parámetros del FHIR:
| Parámetro | Tipo | Obligatorio | Description (Descripción) |
| --- | --- | --- | --- |
| `MemberPatient` | Paciente | Sí | Recurso para pacientes que contiene información demográfica sobre el miembro al que se va a vincular. |
| `CoverageToMatch` | Cobertura | Sí | Recurso de cobertura que se utilizará para compararlo con los registros existentes. |
| `CoverageToLink` | Cobertura | No | Recurso de cobertura que se vinculará durante el proceso de emparejamiento. |
| `Consent` | Consentimiento | Sí | También se almacena el recurso de consentimiento para fines de autorización. Esto es diferente de la `$member-match` operación individual en la que *no* se requiere el consentimiento. |
## Solicitud POST para enviar un trabajo de emparejamiento masivo de miembros
El siguiente ejemplo muestra una solicitud POST para enviar un trabajo de emparejamiento masivo de miembros. Cada miembro está incluido en un `MemberBundle` parámetro que contiene los `Consent` recursos necesarios `MemberPatient` y uno opcional`CoverageToLink`. `CoverageToMatch`
```
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"
}
]
}
}
]
}
]
}
```
## Respuesta al trabajo completada con salida
Cuando se completa el trabajo, la respuesta incluye los metadatos del trabajo y un recurso de parámetros del FHIR que contiene tres recursos del grupo que clasifican los resultados de la coincidencia.
```
{
"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 del grupo de salida
El trabajo completado devuelve un recurso de parámetros que contiene tres recursos de grupo:
**MatchedMembers Group (Grupo)**
Contiene las referencias de los pacientes de todos los miembros seleccionados correctamente y no se clasifica como restricción de consentimiento.
El `Group.quantity` campo contiene el recuento total de miembros de cada uno de sus grupos respectivos.
**NonMatchedMembers Group (Grupo)**
Contiene referencias a miembros en los que no se encontró ninguna coincidencia o se identificaron varias coincidencias.
**ConsentConstrainedMembers Group (Grupo)**
Contiene las referencias de los pacientes de todos los miembros emparejados correctamente cuando las restricciones de consentimiento impiden el intercambio de datos. Un recurso de consentimiento se considera limitado cuando se dan las dos condiciones siguientes:
+ **El URI de la política termina en `#sensitive`**: es la señal más clara y directa. El pagador que los envía dice explícitamente: «Los datos de este miembro son confidenciales; trátelos con cuidado».
```
"policy": [{ "uri": "...hrex-consent.html#sensitive" }]
```
+ **El tipo de disposición de nivel superior es `deny`**: el miembro se ha negado ampliamente a compartir datos.
```
"provision": { "type": "deny" }
```
## Integración con \$1 davinci-data-export
El recurso del MatchedMembers grupo devuelto por se `$bulk-member-match` puede utilizar directamente con la `$davinci-data-export` operación para recuperar datos masivos de los miembros:
```
POST [base]/Group/{matched-group-id}/$davinci-data-export
GET [base]/Group/{matched-group-id}
```
Esta integración permite flujos de trabajo eficientes en los que primero se identifican los miembros coincidentes de forma masiva y, a continuación, se exportan sus historiales médicos completos utilizando el recurso del grupo resultante.
## Características de rendimiento
La `$bulk-member-match` operación está diseñada para el procesamiento de grandes volúmenes y se ejecuta de forma asíncrona:
+ **Simultaneidad**: máximo de 5 operaciones simultáneas por almacén de datos.
+ **Escalabilidad**: gestiona hasta 500 miembros por solicitud (límite de carga útil de 5 MB).
+ **Operaciones paralelas**: compatible con operaciones simultáneas de importación, exportación o eliminación masiva.
## Autorización
La API utiliza el protocolo de autorización SMART on FHIR con los siguientes ámbitos obligatorios:
+ `system/Patient.read`— Necesaria para buscar y comparar los recursos de los pacientes.
+ `system/Coverage.read`— Necesario para validar la información de cobertura.
+ `system/Group.write`— Necesario para crear los recursos del grupo de resultados.
+ `system/Organization.read`— Condicional, obligatorio si la cobertura hace referencia a organizaciones.
+ `system/Practitioner.read`— Condicional, obligatorio si la cobertura hace referencia a profesionales.
+ `system/PractitionerRole.read`— Condicional, obligatorio si la cobertura hace referencia a las funciones de los profesionales.
+ `system/Consent.write`— Condicional, obligatorio si se proporcionan recursos de consentimiento.
La operación también admite la autorización de la versión 4 (SiGv4) de AWS IAM Signature para el acceso programático.
## Gestión de errores
La operación gestiona las siguientes condiciones de error:
+ **400 Solicitud errónea**: el formato de solicitud no es válido, faltan los parámetros necesarios o la carga útil supera los límites de tamaño (500 miembros o 5 MB).
+ **422 Entidad inprocesable**: errores de procesamiento durante la ejecución del trabajo.
+ **Errores de miembros individuales**: cuando un miembro específico no se procesa, la operación continúa con los miembros restantes e incluye los detalles del error en el NonMatchedMembers grupo con los códigos de motivo correspondientes. Por ejemplo, si `MemberBundle` a un paciente le falta el `birthDate` parámetro, se mostrará el siguiente error:
```
"errors": [
{
"memberIndex": 1,
"jsonBlob": {
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "invalid",
"diagnostics": "MemberPatient.birthDate is required"
}
],
"statusCode": 400
}
}
]
```
Los detalles del error están disponibles en el punto final del sondeo de estado e incluyen:
+ `numberOfMembersWithCustomerError`: Recuento de miembros con errores de validación o entrada.
+ `numberOfMembersWithServerError`: Recuento de miembros con errores de procesamiento en el servidor.
## Operaciones de relacionadas
+ [`$member-match`operación para HealthLake](reference-fhir-operations-member-match.md)— Operación de emparejamiento de miembros individuales.
+ [Funcionamiento FHIR R4 `$davinci-data-export` para HealthLake](reference-fhir-operations-davinci-data-export.md)— Exportación masiva de datos utilizando recursos del grupo.
+ [FHIR R4 para `$operations` HealthLake](reference-fhir-operations.md)— Lista completa de operaciones compatibles.
# Funcionamiento FHIR R4 `$confirm-attribution-list` para HealthLake
Indica a un productor que el consumidor no tiene más cambios que hacer en la lista de atribuciones. Esta operación finaliza la lista de atribuciones eliminando los miembros inactivos de la lista, cambiando el estado a «final» y confirmando la operación. Esta operación forma parte de la implementación de la IG 2.1.0 de la [Lista de Atribución de Miembros (ATR) del FHIR](https://build.fhir.org/ig/HL7/davinci-atr/spec.html).
## Punto de conexión
```
POST [base]/Group/[id]/$confirm-attribution-list
```
## Solicitud
No se requieren parámetros.
```
POST [base]/Group/[id]/$confirm-attribution-list
```
## Respuesta
Devuelve HTTP 201 con un mensaje de confirmación.
### Respuesta de ejemplo
```
HTTP Status Code: 201
{
"resourceType": "Parameters",
"parameter": [
{
"name": "message",
"valueString": "Accepted."
}
]
}
```
## Estado del grupo tras la confirmación
Tras la confirmación correcta, el estado de la lista de atribuciones del recurso del grupo pasará a ser «final»:
```
{
"resourceType": "Group",
"id": "fullexample",
"extension": [
{
"url": "http://hl7.org/fhir/us/davinci-atr/StructureDefinition/ext-attributionListStatus",
"valueCode": "final"
}
]
// ... other Group properties
}
```
## Gestión de errores
La operación gestiona las siguientes condiciones de error:
| Error | Estado HTTP | Description (Descripción) |
| --- | --- | --- |
| Solicitud de operación no válida | 400 | Estructura o parámetros de solicitud no conformes |
| No se encontró el recurso de grupo | 404 | El ID de grupo especificado no existe |
## Autorización y seguridad
Requisitos de SMART Scope
Los clientes deben tener los privilegios adecuados para leer los recursos del grupo y los recursos de atribución relacionados
Pues`$confirm-attribution-list`, los clientes también deben tener privilegios de escritura para modificar los recursos del grupo
Los mecanismos de autorización estándar del FHIR se aplican a todas las operaciones
# Funcionamiento FHIR R4 `$davinci-data-export` para HealthLake
La `$davinci-data-export` operación es una operación FHIR asíncrona desde la que puede exportar datos de atención médica. AWS HealthLake Esta operación admite varios tipos de exportación, como la atribución de miembros (ATR), el acceso a PDex proveedores y el acceso a miembros. Payer-to-Payer APIs Es una versión especializada de la `$export` operación estándar del FHIR, diseñada para cumplir con los requisitos de las guías de DaVinci implementación.
## Características principales de
+ *Procesamiento asíncrono*: sigue el patrón estándar de solicitudes asíncronas del FHIR
+ Exportación a *nivel de grupo: exporta los datos de los miembros de un recurso grupal* específico
+ *Múltiples tipos de exportación*: admite ATR (atribución de miembros), acceso a PDex proveedores y Payer-to-Payer acceso a miembros APIs
+ *Soporte integral de perfiles*: incluye US Core, CARIN Blue Button y PDex perfiles
+ *Filtrado flexible*: admite el filtrado por pacientes, tipos de recursos y rangos de tiempo
+ *Salida NDJSON*: proporciona datos en formato JSON delimitado por líneas nuevas
## Punto final de la operación
```
GET [base]/Group/[id]/$davinci-data-export
POST [base]/Group/[id]/$davinci-data-export
```
## Parámetros de la solicitud
| Parámetro | Cardinalidad | Description (Descripción) |
| --- | --- | --- |
| patient | 0.. \$1 | Miembros específicos cuyos datos se van a exportar. Si se omite, se exportan todos los miembros del grupo. |
| \$1type | 0.1. | Lista delimitada por comas de los tipos de recursos del FHIR que se van a exportar. |
| \$1since | 0.1 | Incluya únicamente los recursos actualizados después de esta fecha y hora. |
| \$1until | 0.1.. | Incluya únicamente los recursos actualizados antes de esta fecha y hora. |
| exportType | 0.1.. | Tipo de exportación que se va a realizar. 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. Predeterminado: hl7.fhir.us.davinci-atr. |
| \$1includeEOB2xWoFinancial | 0.1.. | Especifica si se deben incluir los ExplanationOfBenefit recursos de CARIN BB 2.x sin datos financieros. Predeterminado: false. |
### Tipos de recursos admitidos
Los tipos de recursos admitidos dependen del tipo de exportación que especifique. Para las exportaciones ATR, se admiten los siguientes tipos de recursos:
+ `Group`
+ `Patient`
+ `Coverage`
+ `RelatedPerson`
+ `Practitioner`
+ `PractitionerRole`
+ `Organization`
+ `Location`
Para PDex las exportaciones (Provider Access y Member Access), se admiten todos los tipos de recursos clínicos y de reclamaciones, además de los tipos anteriores. Payer-to-Payer Para obtener una lista completa de los tipos de recursos compatibles, consulte la [Guía de implementación básica de EE. UU. (STU 6.1)](https://hl7.org/fhir/us/core/STU6.1/), la Guía de implementación de [CARIN Blue Button y la Guía de implementación](https://hl7.org/fhir/us/carin-bb/) del [soporte de autorización previa de Da Vinci](https://hl7.org/fhir/us/davinci-pas/).
## Tipos de exportación
La `$davinci-data-export` operación admite los siguientes tipos de exportación. El tipo de exportación se especifica mediante el `exportType` parámetro.
| Tipo de exportación | Finalidad | Alcance de los datos | Límite temporal |
| --- | --- | --- | --- |
| hl7.fhir.us.davinci-atr | Lista de atribuciones de miembros | Recursos relacionados con la atribución | Ninguno |
| hl7.fhir.us.davinci-pdex | API de acceso para proveedores | Datos clínicos y de reclamaciones de los pacientes atribuidos | 5 años |
| hl7.fhir.us.davinci-pdex.p2p | Payer-to-Payer Intercambio | Datos históricos de los miembros para las transiciones de seguros | 5 años |
| hl7.fhir.us.davinci-pdex.member | API de acceso para miembros | Datos de salud propios del miembro | 5 años |
**nota**
En el caso de PDex las exportaciones, el límite temporal de 5 años no se aplica a los tipos de recursos ATR (`Group``Patient``Coverage`,`RelatedPerson`,`Practitioner`,`PractitionerRole`,`Organization`,`Location`). Estos recursos siempre se incluyen independientemente de la edad.
### ATR (hl7.fhir.us.davinci-atr)
Con el tipo de exportación ATR, puedes exportar los datos de la lista de atribución de miembros. Usa este tipo de exportación para recuperar recursos relacionados con la atribución para los miembros de un grupo. Para obtener más información, consulte la operación de [exportación de ATR de Da Vinci](https://build.fhir.org/ig/HL7/davinci-atr/OperationDefinition-davinci-data-export.html).
Tipos de recursos admitidos
`Group`, `Patient`, `Coverage`, `RelatedPerson`, `Practitioner`, `PractitionerRole`, `Organization`, `Location`
Filtrado temporal
No se aplica ningún filtrado temporal. Todos los recursos coincidentes se exportan independientemente de la fecha.
### PDex Tipos de exportación
Todos los tipos de PDex exportación comparten los mismos perfiles compatibles y la misma lógica de filtrado. Para obtener más información, consulte la [API de Da Vinci PDex Provider Access](https://build.fhir.org/ig/HL7/davinci-epdx/provider-access-api.html). Se admiten los siguientes perfiles:
+ US Core 3.1.1, 6.1.0 y 7.0.0
+ PDex Autorización previa (no se admite para el acceso de los miembros)
+ Perfiles básicos de CARIN BB 2.x: pacientes hospitalizados, ambulatorios, institucionales, profesionales, orales, farmacéuticos NonClinician
Acceso para proveedores () `hl7.fhir.us.davinci-pdex`
Permite a los proveedores de la red recuperar los datos de los pacientes atribuidos.
Payer-to-Payer (`hl7.fhir.us.davinci-pdex.p2p`)
Permite el intercambio de datos entre los pagadores cuando un paciente cambia de seguro.
Acceso de miembros () `hl7.fhir.us.davinci-pdex.member`
Permite a los miembros acceder a sus propios datos de salud. Este tipo de exportación puede incluir datos financieros en los recursos de reclamaciones.
## Lógica de inclusión y soporte de perfiles
En el caso de PDex las exportaciones, la `$davinci-data-export` operación utiliza declaraciones de perfil en el `meta.profile` elemento para determinar qué recursos incluir en la exportación.
### ExplanationOfBenefit Manejo de recursos
`ExplanationOfBenefit`Los recursos (EOB) se incluyen o excluyen de PDex las exportaciones en función de sus `meta.profile` declaraciones:
+ ExplanationOfBenefit los recursos con un perfil CARIN BB 1.x se excluyen de la exportación.
+ ExplanationOfBenefit los recursos sin ningún `meta.profile` conjunto se excluyen de la exportación.
+ ExplanationOfBenefit siempre se incluyen los recursos con un perfil CARIN BB 2.x Basis.
+ ExplanationOfBenefit los recursos con un perfil CARIN BB 2.x que contiene datos financieros se excluyen de forma predeterminada. Cuando `_includeEOB2xWoFinancial=true` están configurados, se incluyen sin datos financieros y el recurso se transforma en el perfil base correspondiente.
+ ExplanationOfBenefit los recursos con un perfil de autorización PDex previa siempre se incluyen.
### Transformación de datos financieros
Cuando se configura`_includeEOB2xWoFinancial=true`, la operación transforma los ExplanationOfBenefit recursos de [CARIN BB 2.x en](https://hl7.org/fhir/us/carin-bb/) sus perfiles básicos correspondientes mediante la eliminación de los datos financieros. Por ejemplo, un `C4BB ExplanationOfBenefit Oral` recurso se transforma en`C4BB ExplanationOfBenefit Oral Basis`, lo que elimina los datos financieros del registro según la especificación de la FHIR.
Los siguientes elementos de datos financieros se eliminan durante la transformación:
+ Todos los elementos se dividen `total`
+ Todos los `adjudication` elementos con rebanada `amounttype`
+ Todos los `item.adjudication` elementos con información sobre el importe
La operación también actualiza los metadatos del perfil durante la transformación:
+ `meta.profile`se actualiza a la URL canónica del perfil básico
+ La versión se ha actualizado a la versión básica CARIN BB 2.x
+ Los recursos existentes en el almacén de datos no se modifican
+ Los recursos exportados no se devuelven al almacén de datos
### Reglas de detección de perfiles
La operación utiliza las siguientes reglas para detectar y validar los perfiles:
+ La detección de versiones se basa en la versión `meta.profile` canónica URLs
+ Se incluye un recurso si ALGUNO de sus perfiles declarados coincide con los criterios de exportación
+ La validación del perfil se produce durante el procesamiento de la exportación
## Filtrado temporal de cinco años para PDex las exportaciones
Para todos los tipos de PDex exportación, HealthLake aplica un filtro temporal de 5 años en función de cuándo se actualizó el recurso por última vez. El filtro temporal se aplica a todos los recursos, excepto a los siguientes tipos de recursos de atribución principales, que siempre se exportan independientemente de su antigüedad:
+ `Patient`
+ `Coverage`
+ `Organization`
+ `Practitioner`
+ `PractitionerRole`
+ `RelatedPerson`
+ `Location`
+ `Group`
Estos recursos administrativos y demográficos están exentos porque proporcionan un contexto esencial para los datos exportados. Las exportaciones de ATR no están sujetas a ningún filtrado temporal.
## Solicitudes de ejemplo
Los siguientes ejemplos muestran cómo iniciar trabajos de exportación para diferentes tipos de exportación.
*Exportación 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"
}
}
}
```
*Exportación de Provider Access con eliminación de datos ExplanationOfBenefit financieros*
```
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
```
*Exportación de Member Access para un 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
```
## Respuesta de ejemplo
```
{
"datastoreId": "eaee622d8406b41eb86c0f4741201ff9",
"jobStatus": "SUBMITTED",
"jobId": "48d7b91dae4a64d00d54b70862f33f61"
}
```
## Relaciones de recursos
La operación exporta los recursos en función de sus relaciones dentro de la lista de atribuciones de miembros:
```
Group (Attribution List)
├── Patient (Members)
├── Coverage → RelatedPerson (Subscribers)
├── Practitioner (Attributed Providers)
├── PractitionerRole → Location
└── Organization (Attributed Providers)
```
### Fuentes de recursos
| Recurso | Ubicación de la fuente | Description (Descripción) |
| --- | --- | --- |
| Patient | Group.member.entity | Los pacientes que son miembros de la lista de atribuciones |
| Coverage | Group.member.extension:coverageReference | Cobertura que dio lugar a la afiliación de los pacientes |
| Organization | Group.member.extension:attributedProvider | Organizaciones a las que se atribuyen los pacientes |
| Practitioner | Group.member.extension:attributedProvider | Profesionales individuales a los que se atribuyen los pacientes |
| PractitionerRole | Group.member.extension:attributedProvider | Funciones de los profesionales a las que se atribuyen los pacientes |
| RelatedPerson | Coverage.subscriber | Suscriptores de la cobertura |
| Location | PractitionerRole.location | Ubicaciones asociadas a las funciones de los profesionales |
| Group | Punto final de entrada | La propia lista de atribuciones |
## Gestión de trabajos
Comprobar el estado del trabajo
`GET [base]/export/[job-id]`
Cancelar trabajo
`DELETE [base]/export/[job-id]`
### Ciclo de vida del trabajo
+ `SUBMITTED`- Se ha recibido el trabajo y se ha puesto en cola
+ `IN_PROGRESS`- Job se está procesando activamente
+ `COMPLETED`- Job finalizado correctamente, archivos disponibles para descargar
+ `FAILED`- El trabajo encontró un error
## Output Format (Formato de salida)
+ *Formato de archivo*: NDJSON (JSON delimitado por nueva línea)
+ *Organización de archivos*: archivos separados para cada tipo de recurso
+ *Extensión de archivo*: .ndjson
+ *Ubicación: depósito* y ruta de S3 especificados
## Gestión de errores
La operación devuelve una solicitud incorrecta de HTTP 400 con un valor OperationOutcome para las siguientes condiciones:
Errores de autorización
La función de IAM especificada en `DataAccessRoleArn` no tiene permisos suficientes para realizar la operación de exportación. Para ver la lista completa de los permisos de S3 y KMS necesarios, consulte [Configurar los permisos para los trabajos de exportación](getting-started-setting-up.md#setting-up-export-permissions).
Errores de validación de parámetros
+ El `patient` parámetro no tiene el formato `Patient/id,Patient/id,...`
+ Una o más referencias de pacientes no son válidas o no pertenecen al grupo especificado
+ El valor del `exportType` parámetro no es un tipo de exportación compatible
+ El `_type` parámetro contiene tipos de recursos que no son compatibles con el tipo de exportación especificado
+ En el `_type` parámetro faltan los tipos de recursos necesarios (`Group`,`Patient`,`Coverage`) para el tipo de `hl7.fhir.us.davinci-atr` exportación
+ El valor del `_includeEOB2xWoFinancial` parámetro no es un booleano válido
Errores de validación de recursos
+ El recurso de grupo especificado no existe en el banco de datos
+ El recurso de grupo especificado no tiene miembros
+ Uno o más miembros del grupo hacen referencia a recursos para pacientes que no existen en el almacén de datos
## Seguridad y autorización
+ Se aplican los mecanismos de autorización estándar del FHIR
+ La función de acceso a los datos debe tener los permisos de IAM necesarios para las operaciones de S3 y KMS. Para ver la lista completa de los permisos necesarios, consulte [Configurar los permisos para los trabajos de exportación](getting-started-setting-up.md#setting-up-export-permissions).
## Prácticas recomendadas
+ *Selección del tipo de recurso*: solicite únicamente los tipos de recursos que necesite para minimizar el tamaño de la exportación y el tiempo de procesamiento
+ *Filtrado basado en el tiempo*: utilice el `_since` parámetro para exportaciones incrementales
+ *Filtrado de pacientes*: utilice el `patient` parámetro cuando solo necesite datos de miembros específicos
+ *Supervisión del trabajo*: compruebe periódicamente el estado del trabajo para grandes exportaciones
+ *Gestión de errores*: Implemente la lógica de reintento adecuada para los trabajos fallidos
+ *Conocimiento del filtro temporal*: para PDex las exportaciones, tenga en cuenta el filtro temporal de 5 años al seleccionar los tipos de recursos
+ *Eliminación de datos financieros*: `_includeEOB2xWoFinancial=true` utilícelo cuando necesite datos de reclamaciones sin información financiera
+ *Gestión de perfiles*: asegúrese de que los recursos cuenten con las declaraciones de perfil adecuadas, compárelos con los perfiles de destino antes de su ingestión y utilice el control de versiones de los perfiles para controlar el comportamiento de exportación
## Limitaciones
+ Se puede especificar un máximo de 500 pacientes en el parámetro `patient`
+ La exportación se limita únicamente a las operaciones a nivel de grupo
+ Solo admite el conjunto predefinido de tipos de recursos para cada tipo de exportación
+ La salida siempre está en formato NDJSON
+ PDex las exportaciones están limitadas a 5 años de datos clínicos y de reclamaciones
+ La transformación de datos financieros solo se aplica a los perfiles CARIN BB 2.x ExplanationOfBenefit
## Recursos adicionales
+ [Lista de atribuciones de miembros de Da Vinci (IG)](https://build.fhir.org/ig/HL7/davinci-atr/)
+ [Intercambio de datos de jugadores Da Vinci IG](https://hl7.org/fhir/us/davinci-pdex/)
+ [Sistema de intercambio de datos de pagadores dirigido al consumidor de CARIN](https://build.fhir.org/ig/HL7/carin-bb/)
+ [Guía de implementación básica de EE. UU.](https://www.hl7.org/fhir/us/core/)
+ [Especificación de acceso masivo a datos del FHIR](https://hl7.org/fhir/uv/bulkdata/)
# Generación de documentos clínicos con `$document`
AWS HealthLake ahora es compatible con el `$document` funcionamiento de los recursos de Composition, lo que le permite generar un documento clínico completo agrupando la composición con todos sus recursos de referencia en un único paquete cohesivo. Esta operación es esencial para las aplicaciones de atención médica que necesitan:
+ Cree documentos clínicos estandarizados
+ Intercambie los registros completos de los pacientes
+ Almacene documentación clínica completa
+ Genere informes que incluyan todo el contexto relevante
## De uso
La `$document` operación se puede invocar en los recursos de Composition mediante los métodos GET y POST:
**Operaciones admitidas**
```
GET/POST [base]/Composition/[id]/$document
```
## Parámetros admitidos
HealthLake admite el siguiente `$document` parámetro FHIR:
| Parámetro | Tipo | Obligatorio/a | Predeterminado | Description (Descripción) |
| --- | --- | --- | --- | --- |
| persist | booleano | No | false | Booleano que indica si el servidor debe almacenar el paquete de documentos generado |
## Ejemplos
**Solicitud GET**
```
GET [base]/Composition/180f219f-97a8-486d-99d9-ed631fe4fc57/$document?persist=true
```
**Solicitud POST con parámetros**
```
POST [base]/Composition/180f219f-97a8-486d-99d9-ed631fe4fc57/$document
Content-Type: application/fhir+json
{
"resourceType": "Parameters",
"parameter": [
{
"name": "persist",
"valueBoolean": true
}
]
}
```
**Respuesta de ejemplo**
La operación devuelve un recurso de paquete del tipo «documento» que contiene la composición y todos los recursos a los que se hace referencia:
```
{
"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"
}
]
}
}
}
]
}
```
## Comportamiento
La `$document` operación:
1. Toma el recurso de composición especificado como base del documento
1. Identifica y recupera todos los recursos a los que hace referencia directamente la composición
1. Empaqueta la composición y todos los recursos a los que se hace referencia en un paquete del tipo «documento»
1. Almacena el paquete de documentos generado en el almacén de datos cuando el parámetro de persistencia se establece en true
1. Identifica y recupera los recursos a los que hace referencia indirectamente la composición para una generación completa de documentos
Actualmente, la `$document` operación admite la recuperación de referencias a recursos en el siguiente formato:
1.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. Recurso/ID
Las referencias a recursos no admitidas en el recurso de composición se eliminarán del documento generado.
## Gestión de errores
La operación gestiona las siguientes condiciones de error:
+ 400 Solicitud errónea: `$document` operación no válida (solicitud no conforme) o si el documento resultante no pasa la validación del FHIR debido a que se filtraron las referencias cuando persisten está establecido en true
+ 404 No encontrado: no se ha encontrado el recurso de composición
Para obtener más información sobre la especificación de la `$document` operación, consulte la documentación de [composición `$document` del FHIR R4](https://www.hl7.org/fhir/R4/composition-operation-document.html).
# Eliminar recursos de forma permanente con `$erase`
AWS HealthLake admite la `$erase` operación, lo que permite la eliminación permanente de un recurso específico y sus versiones históricas. Esta operación resulta especialmente útil cuando se necesita:
+ Eliminar permanentemente los recursos individuales
+ Eliminar historiales de versiones específicos
+ Gestione los ciclos de vida de los recursos individuales
+ Cumpla con los requisitos específicos de eliminación de datos
## De uso
La `$erase` operación se puede invocar en dos niveles:
**Nivel de instancia de recurso**
```
POST [base]/[ResourceType]/[ID]/$erase?deleteAuditEvent=true
```
**Nivel específico de la versión**
```
POST [base]/[ResourceType]/[ID]/_history/[VersionID]/$erase
```
## Parameters
| Parámetro | Tipo | Obligatorio/a | Predeterminado | Description (Descripción) |
| --- | --- | --- | --- | --- |
| deleteAuditEvent | booleano | No | false | Si es verdadero, elimina los eventos de auditoría asociados |
## Ejemplos
**Solicitud de ejemplo**
```
POST [base]/Patient/example-patient/$erase
```
**Respuesta de ejemplo**
```
{
"jobId": "5df47e2f51ff3c731847678cb8cad48e",
"jobStatus": "SUBMITTED"
}
```
## Estado del trabajo
Para comprobar el estado de un trabajo de borrado:
```
GET [base]/$erase/[jobId]
```
La operación devuelve información sobre el estado del trabajo:
```
{
"datastoreId": "36622996b1fcecb7e12ee2ee085308d3",
"jobId": "5df47e2f51ff3c731847678cb8cad48e",
"status": "COMPLETED",
"submittedTime": "2025-10-30T16:39:24.160Z"
}
```
## Comportamiento
La `$erase` operación:
1. Procesa de forma asíncrona para garantizar la integridad de los datos
1. Mantiene las transacciones ACID
1. Proporciona un seguimiento del estado del trabajo
1. Elimina permanentemente el recurso especificado y sus versiones
1. Incluye un registro de auditoría completo de las actividades de eliminación
1. Soporta la eliminación selectiva de eventos de auditoría
## Registro de auditoría
La `$erase` operación se registra DeleteResource con el ID de usuario, la marca de tiempo y los detalles del recurso.
## Limitaciones
+ `$erased`el recurso no aparecerá en los resultados de búsqueda ni `_history` en las consultas.
+ Es posible que los recursos que se estén borrando estén inaccesibles temporalmente durante el procesamiento
+ La medición del almacenamiento se ajusta inmediatamente a medida que los recursos se eliminan permanentemente
# Obtener datos de pacientes con `Patient/$everything`
La `Patient/$everything` operación se utiliza para consultar un `Patient` recurso del FHIR, junto con cualquier otro recurso relacionado con él. `Patient` La operación se puede utilizar para proporcionar a un paciente acceso a su historial completo o para que un proveedor realice una descarga masiva de datos relacionados con un paciente. HealthLakeapoyos `Patient/$everything` para un paciente específico`id`.
`Patient/$everything`es una operación de la API REST del FHIR que se puede invocar como se muestra en los ejemplos siguientes.
------
#### [ GET request ]
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything
```
------
**nota**
Los recursos en respuesta se ordenan por tipo de recurso y recurso`id`.
La respuesta siempre se rellena con`Bundle.total`.
## Parámetros `Patient/$everything`
HealthLake admite los siguientes parámetros de consulta
| Parámetro | Details |
| --- | --- |
| iniciar | Obtenga todos los `Patient` datos después de una fecha de inicio especificada. |
| finales | Obtenga todos los `Patient` datos antes de una fecha de finalización especificada. |
| since | Actualice todos `Patient` los datos después de una fecha específica. |
| \$1tipo | Obtenga `Patient` datos para tipos de recursos específicos. |
| \$1count | Obtenga `Patient` datos y especifique el tamaño de la página. |
**Example - Obtenga todos los datos del paciente después de una fecha de inicio específica**
`Patient/$everything`puede usar el `start` filtro para consultar solo los datos después de una fecha específica.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?start=2024-03-15T00:00:00.000Z
```
**Example - Obtenga todos los `Patient` datos antes de una fecha de finalización especificada**
El paciente \$1everything puede usar el `end` filtro solo para consultar datos anteriores a una fecha específica.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?end=2024-03-15T00:00:00.000Z
```
**Example - Actualice todos los `Patient` datos después de una fecha específica**
`Patient/$everything`puede usar el `since` filtro para consultar solo los datos actualizados después de una fecha específica.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?since=2024-03-15T00:00:00.000Z
```
**Example - Obtenga `Patient` datos para tipos de recursos específicos**
El paciente \$1everything puede usar el `_type` filtro para especificar tipos de recursos específicos que se incluirán en la respuesta. Se pueden especificar varios tipos de recursos en una lista separada por comas.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?_type=Observation,Condition
```
**Example - Obtenga `Patient` datos y especifique el tamaño de la página**
Patient \$1everything puede usar el `_count` para configurar el tamaño de la página.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id/$everything?_count=15
```
## `Patient/$everything``start`y atributos `end`
HealthLake admite los siguientes atributos de recurso para los parámetros de `end` consulta `Patient/ $everything` `start` y.
| Recurso | Elemento de recurso |
| --- | --- |
| Cuenta | Account.ServicePeriod.start |
| AdverseEvent | AdverseEvent.fecha |
| AllergyIntolerance | AllergyIntolerance. Fecha de registro |
| Cita | Cita. Inicio |
| AppointmentResponse | AppointmentResponse.iniciar |
| AuditEvent | AuditEvent.periodo.inicio |
| Basic | Básico. Creado |
| BodyStructure | NO\$1DATE |
| CarePlan | CarePlan.periodo.inicio |
| CareTeam | CareTeam.periodo.inicio |
| ChargeItem | ChargeItem. occurrenceDateTime, ChargeItem .OccurrencePeriod.Start, .OccurrenceTiming.Event ChargeItem |
| Reclamación | Reclamación. Periodo facturable. Start |
| ClaimResponse | ClaimResponse.creado |
| ClinicalImpression | ClinicalImpression.fecha |
| Comunicación | Comunicación. Enviada |
| CommunicationRequest | CommunicationRequest. occurrenceDateTime,. Periodo de aparición CommunicationRequest. Inicio |
| Composición | Composición.Fecha |
| Condición | Condición. Fecha de registro |
| Consentimiento | Consentimiento. Fecha y hora |
| Cobertura | Cobertura. Periodo. Inicio |
| CoverageEligibilityRequest | CoverageEligibilityRequest.creado |
| CoverageEligibilityResponse | CoverageEligibilityResponse.creado |
| DetectedIssue | DetectedIssue.identificado |
| DeviceRequest | DeviceRequest.autor en |
| DeviceUseStatement | DeviceUseStatement. Grabado en |
| DiagnosticReport | DiagnosticReport... efectivo |
| DocumentManifest | DocumentManifest.creado |
| DocumentReference | DocumentReference.context.period.start |
| Encuentro | Encuentro, punto, inicio |
| EnrollmentRequest | EnrollmentRequest.creado |
| EpisodeOfCare | EpisodeOfCare.periodo.inicio |
| ExplanationOfBenefit | ExplanationOfBenefit.Periodo facturable. Inicio |
| FamilyMemberHistory | SIN FECHA |
| Indicador | Bander.Period.Start |
| Objetivo | Objetivo. Fecha de estado |
| Group | SIN FECHA |
| ImagingStudy | ImagingStudy.iniciado |
| Inmunización | Inmunización. Registrada |
| ImmunizationEvaluation | ImmunizationEvaluation.fecha |
| ImmunizationRecommendation | ImmunizationRecommendation.fecha |
| Factura | Factura.fecha |
| Enumeración | Fecha de lista |
| MeasureReport | MeasureReport.periodo.inicio |
| Multimedia | Medios de comunicación. Emitido |
| MedicationAdministration | MedicationAdministration... efectivo |
| MedicationDispense | MedicationDispense. Cuando esté preparado |
| MedicationRequest | MedicationRequest. escrito en |
| MedicationStatement | MedicationStatement.fecha afirmada |
| MolecularSequence | SIN FECHA |
| NutritionOrder | NutritionOrder.Fecha y hora |
| Observación | Observación. Efectiva |
| Paciente | NO\$1DATE |
| Persona | SIN FECHA |
| Procedimiento | Procedimiento. Realizado |
| Procedencia | Procedencia. Periodo ocurrido. Inicio, procedencia. occurredDateTime |
| QuestionnaireResponse | QuestionnaireResponse.creado |
| RelatedPerson | NO\$1DATE |
| RequestGroup | RequestGroup.autor el |
| ResearchSubject | ResearchSubject.. punto |
| RiskAssessment | RiskAssessment. occurrenceDateTime,. Periodo de aparición RiskAssessment. Inicio |
| Schedule | Schedule.Planning Horizon |
| ServiceRequest | ServiceRequest. Autor en |
| Ejemplar | Espécimen. Hora de recepción |
| SupplyDelivery | SupplyDelivery. occurrenceDateTime, SupplyDelivery .OccurrencePeriod.Start, .OccurrenceTiming.Event SupplyDelivery |
| SupplyRequest | SupplyRequest. Escrito el |
| VisionPrescription | VisionPrescription.Fecha de escritura |
# Recuperación de ValueSet códigos con `$expand`
AWS HealthLake ahora es compatible con la `$expand` operación ValueSets que usted haya introducido como cliente, lo que le permite recuperar la lista completa de códigos contenidos en esos ValueSet recursos. Esta operación resulta especialmente útil cuando se necesita:
+ Recupere todos los códigos posibles con fines de validación
+ Muestra las opciones disponibles en las interfaces de usuario
+ Realice búsquedas de código exhaustivas dentro de un contexto terminológico específico
## De uso
La `$expand` operación se puede invocar en ValueSet los recursos mediante los métodos GET y POST:
**Operaciones admitidas**
```
GET/POST [base]/ValueSet/[id]/$expand
GET [base]/ValueSet/$expand?url=http://example.com
POST [base]/ValueSet/$expand
```
## Parámetros admitidos
HealthLake admite un subconjunto de parámetros del FHIR `$expand` R4:
| Parámetro | Tipo | Obligatorio | Description (Descripción) |
| --- | --- | --- | --- |
| url | uri | No | URL canónica del que se va a expandir ValueSet |
| id | id | No | ValueSet identificador del recurso que se va a expandir (para operaciones GET o POST) |
| filter | cadena | No | Filtra el resultado de la expansión del código |
| count | entero | No | Número de códigos a devolver |
| offset | entero | No | Número de códigos coincidentes que se deben omitir antes de la devolución. Se aplica después del filtrado y solo a los códigos coincidentes, no a todo el contenido del original sin filtrar ValueSet |
## Ejemplos
**Solicitud GET por ID**
```
GET [base]/ValueSet/example-valueset/$expand
```
**OBTENGA la solicitud por URL con filtro**
```
GET [base]/ValueSet/$expand?url=http://example.com/ValueSet/my-valueset&filter=male&count=5
```
**Solicitud POST con 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"
}
]
}
```
**Solicitud POST con 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
}
]
}
```
**Respuesta de ejemplo**
La operación devuelve un ValueSet recurso con un `expansion` elemento que contiene los 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"
}
]
}
}
```
La respuesta incluye:
+ expansion.total: número total de códigos en el expandido ValueSet
+ expansion.contains: matriz de códigos expandidos con su sistema, código y valores de visualización
+ expansion.parameter: parámetros utilizados en la solicitud de expansión
Para obtener más información sobre la especificación de `$expand` operación, consulte la documentación del [FHIR](https://build.fhir.org/valueset-operation-expand.html) R4. ValueSet `$expand`
# Exportación HealthLake de datos con FHIR `$export`
Puede exportar datos de forma masiva desde su almacén de HealthLake datos mediante la operación \$1export de FHIR. HealthLake admite el `$export` uso `POST` y las solicitudes del FHIR. `GET` Para realizar una solicitud de exportación`POST`, debe tener un usuario, grupo o rol de IAM con los permisos necesarios, especificarlo `$export` como parte de la solicitud e incluir los parámetros deseados en el cuerpo de la solicitud.
**nota**
Todas las solicitudes de HealthLake exportación realizadas mediante FHIR `$export` se devuelven en `ndjson` formato y se exportan a un bucket de Amazon S3, donde cada objeto de Amazon S3 contiene solo un tipo de recurso FHIR.
Puede poner en cola las solicitudes de exportación según las cuotas de servicio de la AWS cuenta. Para obtener más información, consulte [Cuotas de servicio](reference-healthlake-endpoints-quotas.md#reference-healthlake-quotas).
HealthLake admite los siguientes tres tipos de solicitudes de punto final de exportación masiva.
**HealthLake `$export`tipos masivos**
| Tipo de exportación | Description (Descripción) | Sintaxis |
| --- | --- | --- |
| Sistema | Exporte todos los datos del servidor HealthLake FHIR. | `POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/$export` |
| Todos los pacientes | Exporte todos los datos relacionados con todos los pacientes, incluidos los tipos de recursos asociados al tipo de recurso del 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 los datos relacionados con un grupo de pacientes especificado con un identificador 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 empezar
Cumpla los siguientes requisitos para realizar una solicitud de exportación mediante la API REST del FHIR para HealthLake.
+ Debe haber configurado un usuario, grupo o rol que tenga los permisos necesarios para realizar la solicitud de exportación. Para obtener más información, consulte [Autorizar una solicitud `$export`](#export-rest-auth).
+ Debe haber creado un rol de servicio que conceda HealthLake acceso al bucket de Amazon S3 al que quiere que se exporten sus datos. El rol de servicio también debe especificarse HealthLake como principal de servicio. Para obtener más información sobre la configuración de permisos, consulte[Configurar los permisos para los trabajos de exportación](getting-started-setting-up.md#setting-up-export-permissions).
## Autorizar una solicitud `$export`
Para realizar correctamente una solicitud de exportación mediante la API REST de FHIR, autorice a su usuario, grupo o rol mediante IAM o .0. OAuth2 También debe tener un rol de servicio.
**Autorizar una solicitud mediante IAM**
Al realizar una `$export` solicitud, el usuario, el grupo o el rol deben incluir las acciones de IAM en la política. Para obtener más información, consulte [Configurar los permisos para los trabajos de exportación](getting-started-setting-up.md#setting-up-export-permissions).
**Autorizar una solicitud mediante SMART en el FHIR (2.0) OAuth**
Al realizar una `$export` solicitud en un almacén de HealthLake datos compatible con SMART on FHIR, debe tener asignados los ámbitos adecuados. Para obtener más información, consulte [Los alcances de los recursos de SMART on FHIR son: HealthLake](reference-smart-on-fhir-oauth-scopes.md#smart-on-fhir-scopes-rest).
**nota**
El FHIR `$export` y `GET` las solicitudes requieren el mismo método de autenticación o el mismo token de soporte (en el caso de SMART en el FHIR) para solicitar la exportación y la recuperación de archivos. Los archivos exportados mediante el FHIR `$export` con `GET` están disponibles para su descarga durante 48 horas.
## ¿Hacer una solicitud `$export`
En esta sección se describen los pasos necesarios que debe seguir al realizar una solicitud de exportación mediante la API REST del FHIR.
Para evitar cargos accidentales en tu AWS cuenta, te recomendamos probar tus solicitudes realizando una `POST` solicitud sin proporcionar la `$export` sintaxis.
Para realizar la solicitud, debes hacer lo siguiente:
1. Especifique `$export` en la URL de la `POST` solicitud un punto final compatible.
1. Especifique los parámetros de cabecera necesarios.
1. Especifique el cuerpo de la solicitud que defina los parámetros necesarios.
### Paso 1: especifique `$export` en la URL de la `POST` solicitud un [punto final](reference-healthlake-endpoints-quotas.md#reference-healthlake-endpoints) compatible.
HealthLake admite tres tipos de solicitudes de punto final de exportación masiva. Para realizar una solicitud de exportación masiva, debe realizar una solicitud `POST` basada en uno de los tres puntos de enlace compatibles. Los siguientes ejemplos muestran dónde especificar `$export` en la URL de la solicitud.
+ `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`
Puede utilizar los siguientes parámetros de búsqueda admitidos en la cadena de `POST` solicitud.
#### Parámetros de búsqueda compatibles
HealthLake admite los siguientes modificadores de búsqueda en las solicitudes de exportación masiva.
Los siguientes ejemplos incluyen caracteres especiales que deben codificarse antes de enviar la solicitud.
| Name | ¿Obligatorio? | Description (Descripción) | Ejemplo |
| --- | --- | --- | --- |
| \$1outputFormat | No | El formato para generar los archivos de datos masivos solicitados. Los valores aceptados sonapplication/fhir\$1ndjson,application/ndjson,ndjson. | |
| \$1type | No | Cadena de tipos de recursos FHIR delimitados por comas que desea incluir en su trabajo de exportación. Recomendamos incluirlo \$1type porque esto puede tener repercusiones en los costes cuando se exportan todos los recursos. | &\$1type=MedicationStatement, Observation |
| \$1since | No | Tipos de recursos modificados en o después de la marca de fecha y hora. Si un tipo de recurso no tiene una hora de última actualización, se incluirá en la respuesta. | &\$1since=2024-05-09T00%3A00%3A00Z |
| \$1until | No | Tipos de recursos modificados en o antes de la fecha y hora. Se utiliza en combinación con \$1since para definir un intervalo de tiempo específico para la exportación. Si un tipo de recurso no tiene una hora de última actualización, se excluirá de tu respuesta. | &\$1until=2024-12-31T23%3A59%3A59Z |
### Paso 2: especifique los parámetros de cabecera necesarios
Para realizar una solicitud de exportación mediante la API REST del FHIR, debe especificar los siguientes parámetros de encabezado.
+ Content-Type: `application/fhir+json`
+ Prefiero: `respond-async`
A continuación, debe especificar los elementos necesarios en el cuerpo de la solicitud.
### Paso 3: especifique un cuerpo de solicitud que defina los parámetros necesarios.
La solicitud de exportación también requiere un cuerpo en `JSON` formato. El cuerpo puede incluir los siguientes parámetros.
| Key | ¿Obligatorio? | Description (Descripción) | Valor |
| --- | --- | --- | --- |
| DataAccessRoleArn | Sí | Un ARN de un rol de HealthLake servicio. El rol de servicio utilizado debe especificarse HealthLake como principal de servicio. | arn:aws:iam::444455556666:role/your-healthlake-service-role |
| JobName | No | El nombre de la solicitud de exportación. | your-export-job-name |
| S3Uri | Sí | Parte de una OutputDataConfig clave. El URI de S3 del depósito de destino donde se descargarán los datos exportados. | s3://amzn-s3-demo-bucket/EXPORT-JOB/ |
| KmsKeyId | Sí | Parte de una OutputDataConfig clave. El ARN de la AWS KMS clave utilizada para proteger el bucket de Amazon S3. | arn:aws:kms:region-of-bucket:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab |
**Example Cuerpo de una solicitud de exportación realizada mediante la API REST del FHIR**
Para realizar una solicitud de exportación mediante la API REST del FHIR, debe especificar un cuerpo, como se muestra a continuación.
```
{
"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"
}
}
}
```
Cuando la solicitud se realice correctamente, recibirá la siguiente respuesta.
*Encabezado de respuesta*
```
content-location: https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-job-id
```
*Cuerpo de respuesta*
```
{
"datastoreId": "your-data-store-id",
"jobStatus": "SUBMITTED",
"jobId": "your-export-request-job-id"
}
```
## Gestionar tu solicitud de exportación
Tras realizar correctamente una solicitud de exportación, puedes gestionarla `$export` para describir el estado de una solicitud de exportación actual y `$export` cancelar una solicitud de exportación actual.
Cuando cancelas una solicitud de exportación mediante la API REST, solo se te facturará la parte de los datos que se exportaron hasta el momento en que enviaste la solicitud de cancelación.
En los siguientes temas se describe cómo puede obtener el estado de una solicitud de exportación actual o cancelarla.
### Cancelar una solicitud de exportación
Para cancelar una solicitud de exportación, realice una `DELETE` solicitud e introduzca el identificador de trabajo en la URL de la solicitud.
```
DELETE https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-job-id
```
Cuando la solicitud se realice correctamente, recibirá lo siguiente.
```
{
"exportJobProperties": {
"jobId": "your-original-export-request-job-id",
"jobStatus": "CANCEL_SUBMITTED",
"datastoreId": "your-data-store-id"
}
}
```
Si su solicitud no se acepta, recibirá lo siguiente.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-supported",
"diagnostics": "Interaction not supported."
}
]
}
```
### Describir una solicitud de exportación
Para conocer el estado de una solicitud de exportación, haga una `GET` solicitud utilizando `export` y su`export-request-job-id`.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/export/your-export-request-id
```
La respuesta de JSON contendrá un `ExportJobProperties` objeto. Puede contener los siguientes pares clave-valor.
| Name | ¿Obligatorio? | Description (Descripción) | Valor |
| --- | --- | --- | --- |
| DataAccessRoleArn | No | Un ARN de un rol de HealthLake servicio. El rol de servicio utilizado debe especificarse HealthLake como principal de servicio. | arn:aws:iam::444455556666:role/your-healthlake-service-role |
| SubmitTime | No | Fecha y hora en que se envió un trabajo de exportación. | Apr 21, 2023 5:58:02 |
| EndTime | No | La hora en que se completó un trabajo de exportación. | Apr 21, 2023 6:00:08 PM |
| JobName | No | El nombre de la solicitud de exportación. | your-export-job-name |
| JobStatus | No | | Los valores válidos son:SUBMITTED | IN_PROGRESS | COMPLETED_WITH_ERRORS | COMPLETED |
FAILED
|
| S3Uri | Sí | Parte de un [OutputDataConfig](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_OutputDataConfig.html)objeto. El URI de Amazon S3 del depósito de destino donde se descargarán los datos exportados. | s3://amzn-s3-demo-bucket/EXPORT-JOB/ |
| KmsKeyId | Sí | Parte de un [OutputDataConfig](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_OutputDataConfig.html)objeto. El ARN de la AWS KMS clave utilizada para proteger el bucket de Amazon S3. | arn:aws:kms:region-of-bucket:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab |
**Example : Cuerpo de una solicitud de exportación descrita realizada mediante la API REST del FHIR**
Si se ejecuta correctamente, obtendrá la siguiente respuesta en 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",
}
}
```
# `$inquire`Operación FHIR para HealthLake
La `$inquire` operación le permite comprobar el estado de una solicitud de autorización previa presentada anteriormente. Esta operación implementa la [Guía de implementación de Da Vinci Prior Authorization Support (PAS)](https://hl7.org/fhir/us/davinci-pas/), que proporciona un flujo de trabajo estandarizado basado en el FHIR para recuperar la decisión de autorización actual.
## Funcionamiento
+ **Enviar consulta**: envías un paquete FHIR que contiene la reclamación que deseas comprobar y la información justificativa
+ **Búsqueda**: HealthLake busca la correspondiente ClaimResponse en su almacén de datos
+ **Recuperar**: se recupera el estado de autorización más reciente
+ **Responder**: recibirá una respuesta inmediata con el estado actual de la autorización (en cola, aprobada, denegada, etc.)
**nota**
`$inquire`es una **operación de solo lectura** que recupera el estado de autorización existente. No modifica ni actualiza ningún recurso del almacén de datos.
## Punto de conexión de la API
```
POST /datastore/{datastoreId}/r4/Claim/$inquire
Content-Type: application/fhir+json
```
## Estructura de la solicitud
### Requisitos del paquete
Su solicitud debe ser un recurso del paquete FHIR con:
+ **Tipo de paquete: debe ser** `"collection"`
+ **Bundle.entry****: debe contener exactamente un recurso de reclamación con:**
+ `use = "preauthorization"`
+ `status = "active"`
+ **Recursos de referencia**: todos los recursos a los que se hace referencia en la reclamación deben incluirse en el paquete
**Consulta por ejemplo**
Los recursos de tu paquete de entrada sirven como plantilla de búsqueda. HealthLake utiliza la información proporcionada para localizar el correspondiente ClaimResponse.
### Recursos necesarios de
| Recurso | Cardinalidad | Perfil | Description (Descripción) |
| --- | --- | --- | --- |
| Reclamación | 1 | Consulta de reclamación PAS | La autorización previa sobre la que está solicitando información |
| ¿Paciente | 1 | Paciente beneficiario del PAS | Información demográfica del paciente |
| Organización (aseguradora) | 1 | Organización aseguradora PAS | Compañía de seguros |
| Organización (proveedor) | 1 | Organización solicitante del PAS | Proveedor de atención médica que presentó la solicitud |
### Criterios de búsqueda importantes
HealthLake busca el ClaimResponse uso de:
+ **Referencia del paciente** recogida en la reclamación
+ **Referencia de la aseguradora** en la reclamación
+ **Referencia del proveedor** en la reclamación
+ **Fecha de creación** a partir de la reclamación (como filtro de tiempo)
**Solo consultas específicas para pacientes**
Todas las consultas deben estar vinculadas a un paciente específico. No se permiten consultas en todo el sistema sin la identificación del paciente.
## Ejemplo de solicitud
```
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 las respuestas
### Respuesta correcta (200 OK)
Recibirá un paquete de respuestas a una consulta del PAS que contiene:
+ **ClaimResponse**con el estado de autorización actual; múltiple **ClaimResponse**si coincide con los criterios de búsqueda
+ Todos los recursos originales de tu solicitud (reproducidos)
+ Marca de tiempo del momento en que se recopiló la respuesta
**Posibles resultados ClaimResponse**
| Resultado | Description (Descripción) |
| --- | --- |
| queued | La solicitud de autorización aún está pendiente de revisión |
| complete | Se ha tomado la decisión de autorizar (compruebe si disposition está aprobada o denegada) |
| error | Se ha producido un error durante el procesamiento |
| partial | Autorización 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"
}
}
]
}
```
## Respuestas de error
### 400: solicitud maligna
Se devuelve cuando el formato de la solicitud no es válido o se produce un error en la validación.
```
{
"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 sin autorización
Se devuelve cuando faltan credenciales de autenticación o no son válidas.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "forbidden",
"diagnostics": "Invalid authorization header"
}
]
}
```
### 403: prohibido
Se devuelve cuando el usuario autenticado no tiene permiso para acceder al recurso solicitado.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "exception",
"diagnostics": "Insufficient SMART scope permissions."
}
]
}
```
### 400 Cuando no se encuentra ninguno
Se devuelve cuando no ClaimResponse se encuentra ninguna coincidencia con la 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)"
}]
}
```
### 4.15 Tipo de medio no compatible
Se devuelve cuando el encabezado Content-Type no es application/fhir\$1json.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "value",
"diagnostics": "Incorrect MIME-type. Update request Content-Type header."
}]
}
```
### 429 Demasiadas solicitudes
Se devuelve cuando se superan los límites de velocidad.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "throttled",
"diagnostics": "Rate limit exceeded. Please retry after some time."
}]
}
```
## Reglas de validación
HealthLake realiza una validación exhaustiva de su consulta:
### Validación de paquetes
+ Debe ajustarse al perfil del paquete de solicitud de consulta del PAS
+ `Bundle.type`debe ser `"collection"`
+ Debe contener exactamente un recurso de reclamación
+ Todos los recursos a los que se hace referencia deben incluirse en el paquete
### Validación de la reclamación
+ Debe ajustarse al perfil de consulta de reclamaciones de PAS
+ `Claim.use`debe ser `"preauthorization"`
+ `Claim.status`debe ser `"active"`
+ Campos obligatorios:`patient`,`insurer`,`provider`, `created`
### Validación de recursos
+ Todos los recursos deben ajustarse a sus respectivos perfiles de consulta del PAS
+ Deben estar presentes los recursos de apoyo necesarios (paciente, organización aseguradora, organización proveedora)
+ Las referencias cruzadas deben ser válidas y poder resolverse dentro del paquete
## Especificaciones de rendimiento
| Métrica | Especificación |
| --- | --- |
| Límite de recuento de recursos | 500 recursos por paquete |
| Límite de tamaño del paquete | 5 MB como máximo |
## Permisos necesarios
Para utilizar la `$inquire` operación, asegúrese de que su función de IAM tenga:
+ `healthlake:InquirePreAuthClaim`- Para convocar a la operación
**SMART en FHIR Scopes**
**Alcances mínimos requeridos:**
+ **SMART v1**: `user/ClaimResponse.read`
+ **SMART v2**: `user/ClaimResponse.s`
## Notas importantes sobre la implementación
### Comportamiento de búsqueda
Al enviar una consulta, HealthLake busca el ClaimResponse uso de:
+ **Referencia del paciente** a partir de la reclamación ingresada
+ **Referencia de la aseguradora** a partir de la reclamación ingresada
+ **Referencia del proveedor** a partir de la reclamación ingresada
+ **Fecha de creación** a partir de la reclamación ingresada (como filtro de tiempo)
**Coincidencias múltiples**: si varias ClaimResponses coinciden con sus criterios de búsqueda, HealthLake devuelve todos los resultados coincidentes. Debe usar la `ClaimResponse.created` marca de tiempo más reciente para identificar el estado más reciente.
### Reclamaciones actualizadas
Si has enviado varias actualizaciones a la misma autorización previa (p. ej., Claim v1.1, v1.2 o v1.3), la `$inquire` operación recuperará la versión ClaimResponse asociada a la **versión más reciente** en función de los criterios de búsqueda proporcionados.
### Operación de solo lectura
La `$inquire` operación:
+ **Recupera** el estado de autorización existente
+ **Devuelve** el más reciente ClaimResponse
+ **No** modifica ni actualiza ningún recurso
+ **No** crea nuevos recursos
+ **No** desencadena un nuevo procesamiento de autorizaciones
## Ejemplo de flujo de trabajo
**Flujo de trabajo típico de consultas de autorización previa**
```
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"
```
## Operaciones de relacionadas
+ `Claim/$submit`- Presente una nueva solicitud de autorización previa o actualice una existente
+ `Patient/$everything`- Recupere datos completos de los pacientes para utilizarlos en el contexto de la autorización previa
# Recuperación de detalles conceptuales con `$lookup`
AWS HealthLake ahora admite la `$lookup` operación de CodeSystem recursos, lo que le permite recuperar detalles sobre un concepto específico de un sistema de códigos proporcionando información de identificación, como su código. Esta operación resulta especialmente útil cuando se necesita:
+ Recuperar información detallada sobre códigos médicos específicos
+ Valide el significado y las propiedades del código
+ Acceda a las definiciones y relaciones de los conceptos
+ Support la toma de decisiones clínicas con datos terminológicos precisos
## De uso
La `$lookup` operación se puede invocar en CodeSystem los recursos mediante los métodos GET y POST:
**Operaciones admitidas**
```
GET [base]/CodeSystem/$lookup?system=http://snomed.info/sct&code=73211009&version=20230901
POST [base]/CodeSystem/$lookup
```
## Parámetros admitidos
HealthLake admite un subconjunto de parámetros del FHIR `$lookup` R4:
| Parámetro | Tipo | Obligatorio | Description (Descripción) |
| --- | --- | --- | --- |
| code | code | Sí | El código conceptual que está buscando (por ejemplo, «71620000" en SNOMED CT) |
| system | uri | Sí | [La URL canónica del sistema de códigos (por ejemplo, "http://snomed.info/sct «)](http://snomed.info/sct) |
| version | cadena | No | Versión específica del sistema de códigos |
## Ejemplos
**Solicitud GET**
```
GET [base]/CodeSystem/$lookup?system=http://snomed.info/sct&code=71620000&version=2023-09
```
**Solicitud 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"
}
]
}
```
**Respuesta de ejemplo**
La operación devuelve un recurso de parámetros que contiene los detalles del concepto:
```
{
"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 respuesta
La respuesta incluye los siguientes parámetros cuando están disponibles:
| Parámetro | Tipo | Description (Descripción) |
| --- | --- | --- |
| name | cadena | Nombre del sistema de códigos |
| version | cadena | Versión del sistema de códigos |
| display | cadena | Mostrar el nombre del concepto |
| designation | BackboneElement | Representaciones adicionales para este concepto. |
| property | BackboneElement | Propiedades adicionales del concepto (definición, relaciones, etc.) |
## Comportamiento
La `$lookup` operación:
1. Valida los parámetros necesarios (`code`y`system`)
1. Busca el concepto en el sistema de códigos especificado almacenado en el almacén de datos
1. Devuelve información conceptual detallada, incluidos el nombre para mostrar, las designaciones y las propiedades.
1. Admite búsquedas específicas de la versión cuando se proporciona el parámetro `version`
1. Funciona solo en sistemas de código almacenados explícitamente en el almacén de datos HealthLake
## Gestión de errores
La operación gestiona las siguientes condiciones de error:
+ 400 Solicitud errónea: `$lookup` operación no válida (solicitud no conforme o faltan parámetros obligatorios)
+ 404 No encontrado: no se encontró el sistema de códigos o el código no se encontró en el sistema de códigos especificado
## Advertencias
En esta versión, no se admite lo siguiente:
+ `$lookup`operación mediante la llamada a servidores terminológicos externos
+ `$lookup`operación CodeSystems gestionada por el almacén de datos HealthLake , pero no almacenada explícitamente en él
Para obtener más información sobre la especificación de la `$lookup` operación, consulte la documentación del [FHIR R4](https://www.hl7.org/fhir/R4/codesystem-operation-lookup.html). CodeSystem `$lookup`
# `$member-add`operación para HealthLake
La `$member-add` operación del FHIR añade a un miembro (paciente) a un recurso del grupo, específicamente a una lista de atribuciones de miembros. Esta operación forma parte de la Guía de implementación de las atribuciones de DaVinci los miembros y apoya el proceso de conciliación para gestionar las atribuciones de los miembros.
## Operation Endpoint
```
POST [base]/datastore/{datastoreId}/r4/Group/{groupId}/$member-add
Content-Type: application/json
```
## Parameters
La operación acepta un recurso de parámetros del FHIR con las siguientes combinaciones de parámetros:
### Opciones de parámetros
Puede utilizar una de las siguientes combinaciones de parámetros:
Opción 1: ID de miembro \$1 NPI del proveedor
`memberId` \$1 `providerNpi`
`memberId` \$1 `providerNpi` \$1 `attributionPeriod`
Opción 2: referencia del paciente \$1 referencia del proveedor
`patientReference` \$1 `providerReference`
`patientReference` \$1 `providerReference` \$1 `attributionPeriod`
### Detalles de los parámetros
ID de miembro (opcional)
El identificador del miembro que se va a añadir al grupo.
Tipo: identificador
Sistema: sistema de identificación de pacientes
```
{
"name": "memberId",
"valueIdentifier": {
"system": "http://example.org/patient-id",
"value": "patient-new"
}
}
```
Proveedor NPI (opcional)
El identificador nacional de proveedores (NPI) del proveedor atribuido.
Tipo: identificador
Sistema: http://terminology.hl7. org/CodeSystem/NPI
```
{
"name": "providerNpi",
"valueIdentifier": {
"system": "http://terminology.hl7.org/CodeSystem/NPI",
"value": "1234567890"
}
}
```
Referencia del paciente (opcional)
Referencia directa al recurso para pacientes que se va a añadir.
Tipo: Referencia
```
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/patient-123"
}
}
```
ProviderReference (opcional)
Referencia directa al recurso del proveedor.
Tipo: Referencia
```
{
"name": "providerReference",
"valueReference": {
"reference": "Practitioner/provider-456"
}
}
```
Periodo de atribución (opcional)
El período durante el cual se atribuye el paciente al proveedor.
Tipo: Periodo
```
{
"name": "attributionPeriod",
"valuePeriod": {
"start": "2024-07-15",
"end": "2025-07-14"
}
}
```
## Ejemplos de solicitudes
### Uso de la identificación de miembro y el NPI del proveedor
```
{
"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"
}
}
]
}
```
### Uso de referencias de pacientes y proveedores
```
{
"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 respuesta
### Respuesta de adición exitosa
```
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."
}
}
]
}
```
### Respuestas de error
Sintaxis de solicitud no válida
Estado HTTP: 400 solicitud incorrecta
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "invalid",
"details": {
"text": "Invalid parameter combination provided"
}
}
]
}
```
Recurso no encontrado
Estado HTTP: 404 no encontrado
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-found",
"details": {
"text": "Resource not found."
}
}
]
}
```
Conflicto de versiones
Estado HTTP: 409 Conflicto
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "conflict",
"details": {
"text": "Resource version conflict detected"
}
}
]
}
```
Estado de atribución no válido
Estado HTTP: 422 Entidad inprocesable
```
{
"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'."
}
}
]
}
```
## Reglas de negocio
Validación del estado de la atribución
La operación solo se puede realizar cuando el estado de atribución del grupo es:
+ `draft`
+ `open`
No se permiten operaciones cuando el estado es`final`.
Prevención de miembros duplicados
El sistema evita la adición de miembros duplicados en función de la combinación única de:
+ Identificador de miembro
+ Identificador del pagador
+ Identificador de cobertura
Validación del período de cobertura
Cuando `attributionPeriod` se proporciona uno, debe estar dentro de los límites del período de cobertura del miembro. El sistema hará lo siguiente:
+ Busque el recurso de cobertura del miembro
+ Usa la cobertura más reciente (VersionID más alta) si existen varias
+ Valide que el período de atribución no exceda el período de cobertura
Validación de referencia
Cuando se proporcionan tanto la identificación como la referencia para el mismo recurso (paciente o proveedor), el sistema valida que corresponden al mismo recurso.
Cuando se proporcionan los campos ID y reference.identifier para el mismo recurso (paciente o proveedor), se produce un error.
## Autenticación y autorización
La operación requiere la autorización de SMART on FHIR para:
+ Permisos de lectura: para validar los recursos de pacientes, proveedores y grupos
+ Permisos de búsqueda: para buscar recursos por identificador
+ Permisos de actualización: para modificar el recurso del grupo
## Comportamiento operativo
Actualizaciones de recursos
+ Actualiza el ID de versión del recurso del grupo
+ Crea una entrada en el historial con el estado original del recurso antes de la operación
+ Añade la información de los miembros a la matriz group.Member con:
+ Referencia del paciente en entity.reference
+ Período de atribución en período
+ Información sobre la cobertura y el proveedor en los campos de extensión
Pasos de validación
+ Validación de parámetros: garantiza la validez de las combinaciones de parámetros
+ Existencia de recursos: valida la existencia de recursos para pacientes, proveedores y grupos
+ Estado de atribución: confirma que el estado del grupo permite modificaciones
+ Verificación duplicada: impide añadir miembros existentes
+ Validación de la cobertura: garantiza que el período de atribución esté dentro de los límites de cobertura
## Limitaciones
+ Todos los recursos a los que se hace referencia deben estar en el mismo almacén de datos
+ La operación solo funciona con los recursos del grupo de listas de atribución de miembros
+ Los períodos de atribución deben estar dentro de los límites de cobertura
+ No se pueden modificar los grupos con el estado «final»
# `$member-match`operación para HealthLake
AWS HealthLake ahora apoya la `$member-match` operación de recursos para pacientes, lo que permite a las organizaciones de atención médica encontrar el identificador único de un miembro en diferentes sistemas de salud utilizando información demográfica y de cobertura. Esta operación es esencial para lograr el cumplimiento de los CMS y facilitar el intercambio seguro de payer-to-payer datos, al tiempo que se mantiene la privacidad de los pacientes.
Esta operación resulta especialmente útil cuando se necesita:
+ Permitir el intercambio seguro de datos de salud entre organizaciones
+ Mantenga la continuidad de la atención de los pacientes en los diferentes sistemas
+ Support CMS cumple con los requisitos
+ Facilite la identificación precisa de los miembros en todas las redes de atención médica
## De uso
La `$member-match` operación se puede invocar en los recursos del paciente mediante el método POST:
```
POST [base]/Patient/$member-match
```
## Parámetros admitidos
HealthLake admite los siguientes `$member-match` parámetros del FHIR:
| Parámetro | Tipo | Obligatorio/a | Predeterminado | Description (Descripción) |
| --- | --- | --- | --- | --- |
| MemberPatient | Paciente | Sí | — | Recurso para pacientes que contiene información demográfica sobre el miembro al que se va a vincular |
| CoverageToMatch | Cobertura | Sí | — | Recurso de cobertura que se utilizará para compararlo con los registros existentes |
| CoverageToLink | Cobertura | No | — | Recurso de cobertura que se vinculará durante el proceso de emparejamiento |
| Consentimiento | Consentimiento | No | — | Recurso de consentimiento para fines de autorización |
## Ejemplos
### Solicitud POST con 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"
}
]
}
}
]
}
```
### Respuesta de ejemplo
La operación devuelve un recurso de parámetros que contiene los resultados coincidentes:
```
{
"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 respuesta
La respuesta incluye los siguientes parámetros cuando se encuentra una coincidencia:
| Parámetro | Tipo | Description (Descripción) |
| --- | --- | --- |
| MemberIdentifier | Identificador | El identificador único del miembro coincidente |
| MemberId | Referencia | Referencia al recurso para pacientes |
| Algoritmo de coincidencia | Cadena | Tipo de algoritmo de coincidencia utilizado (EXACT\$1MATCH, STRONG\$1MATCH o DEMOGRAPHIC\$1MATCH) |
| Detalles del partido | Cadena | Información detallada sobre el proceso de emparejamiento |
| Campos coincidentes | Cadena | Lista de campos específicos que se emparejaron correctamente |
## algoritmos coincidentes
La `$member-match` API emplea un enfoque de coincidencia de varios niveles para garantizar una identificación precisa de los miembros:
EXACT\$1MATCH
Utiliza el identificador del paciente combinado con la cobertura SubscriberId
Proporciona el nivel de confianza más alto para la identificación de miembros
STRONG\$1MATCH
Utiliza el identificador del paciente con información de cobertura mínima
Ofrece una gran confianza cuando no se cumplen los criterios de coincidencia exactos
DEMOGRAPHIC\$1MATCH
Se basa en información demográfica básica
Se utiliza cuando no es posible la coincidencia basada en identificadores
## Comportamiento
La operación: `$member-match`
+ Acepta como datos los datos demográficos del paciente, los detalles de la cobertura y la información de consentimiento opcional
+ Devuelve un identificador de miembro único que se puede utilizar en interacciones posteriores
+ Implementa una combinación de varios niveles (exacta, sólida y demográfica) para garantizar una identificación precisa de los miembros en los diferentes sistemas de salud
+ Guarda cualquier información de consentimiento proporcionada para futuros fines de autorización
+ Soporta el intercambio seguro payer-to-payer de datos al tiempo que mantiene la privacidad del paciente
+ Cumple con los requisitos de los CMS para el intercambio de datos sanitarios
## Autorización
La API utiliza el protocolo de autorización SMART on FHIR con los siguientes alcances obligatorios:
+ `system/Patient.read`
+ `system/Coverage.read`
+ `system/Organization.read`(condicional)
+ `system/Practitioner.read`(condicional)
+ `system/PractitionerRole.read`(condicional)
+ `system/Consent.write`(condicional)
## Gestión de errores
La operación gestiona las siguientes condiciones de error:
+ `400 Bad Request`: `$member-match` Operación no válida (solicitud no conforme o faltan parámetros obligatorios)
+ `422 Unprocessable Entity`: No se encontraron coincidencias o se encontraron varias coincidencias
# `$member-remove`operación para HealthLake
La `$member-remove` operación le permite eliminar miembros de una lista de atribución de miembros de la FHIR (recurso grupal) en. AWS HealthLake Esta operación forma parte de la Guía de implementación de la atribución de DaVinci miembros y apoya el proceso de conciliación para gestionar las atribuciones de los miembros.
## Requisitos previos
+ AWS HealthLake Almacén de datos FHIR
+ Permisos de IAM adecuados para las operaciones HealthLake
+ Lista de atribuciones de miembros (recurso grupal) en estado borrador o abierta
## Detalles de la operación
Punto de conexión
`POST /Group/{id}/$member-remove`
Tipo de contenido
`application/fhir+json`
## Parameters
La operación acepta un recurso de parámetros del FHIR con los siguientes parámetros opcionales:
| Parámetro | Cardinalidad | Tipo | Description (Descripción) |
| --- | --- | --- | --- |
| memberId | 0.1 | Identificador | Identificador empresarial del miembro que se va a eliminar |
| NPI del proveedor | 0.1.. | Identificador | NPI del proveedor atribuido |
| Referencia del paciente | 0.1.. | Referencia | Referencia directa al recurso para pacientes |
| Referencia del proveedor | 0.1.. | Referencia | Referencia directa al recurso del proveedor (profesional u organización) PractitionerRole |
| Referencia de cobertura | 0.1.. | Referencia | Referencia al recurso Cobertura |
### Combinaciones de parámetros compatibles
Se admiten las siguientes combinaciones de parámetros:
+ `memberId`solo: elimina todas las atribuciones del miembro especificado
+ `memberId`\$1 `providerNpi` - Elimina las atribuciones de la combinación específica de miembro y proveedor
+ `patientReference`solo: elimina todas las atribuciones del paciente especificado
+ `patientReference`\$1 `providerReference` - Elimina las atribuciones de la combinación específica de paciente y proveedor
+ `patientReference`\$1 `providerReference` \$1 `coverageReference` - Elimina la atribución específica en función del paciente, el proveedor y la cobertura
## Ejemplo de solicitud
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "patientReference",
"valueReference": {
"reference": "Patient/12345"
}
},
{
"name": "providerReference",
"valueReference": {
"reference": "Practitioner/67890"
}
}
]
}
```
## Respuesta
### Respuesta correcta
```
{
"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"
}
]
}
```
## Comportamiento
Requisitos de estado
La operación solo funciona en listas de atribución con estado `draft` o `open`
Las listas con `final` estado rechazarán la operación con un error 422
Proceso de eliminación de miembros
*Borradores de listas de estado*: los miembros se marcan como inactivos (`inactive: true`) y su `changeType` extensión se actualiza a `changed`
*Listas de estado abiertas*: comportamiento similar al estado preliminar
*Listas de estado finales*: se rechaza la operación
Validación
Las referencias se validan para garantizar que existan en el HealthLake almacén de datos
Si se proporcionan tanto el identificador como la referencia para el mismo tipo de recurso, deben corresponder al mismo recurso
Las combinaciones de parámetros se validan de acuerdo con los patrones admitidos
## Gestión de errores
### Respuestas de error comunes
Recurso no 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"]
}
]
}
```
Estado final de la lista de atribuciones (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"]
}
]
}
```
Operación no válida (400)
Se devuelve cuando las combinaciones de parámetros no son válidas o están mal formadas.
Se han encontrado varias coincidencias (412)
Se devuelve cuando los parámetros proporcionados coinciden con varios miembros de la lista de atribuciones.
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "processing",
"diagnostics": "Multiple members found matching the criteria"
}
]
}
```
## Prácticas recomendadas
+ *Utilice parámetros específicos*: cuando sea posible, utilice la combinación de parámetros más específica para evitar eliminaciones involuntarias
+ Estado de la *lista de atribuciones: comprueba el estado* de la lista de atribuciones antes de intentar eliminarla
+ *Maneje los errores con elegancia*: implemente un manejo de errores adecuado para todas las condiciones de error posibles
+ *Valide las referencias*: asegúrese de que existan todos los recursos a los que se hace referencia antes de realizar la solicitud
# Eliminar los recursos del compartimento de pacientes con `$purge`
AWS HealthLake apoya la `$purge` operación, lo que permite la eliminación permanente de todos los recursos del compartimento del paciente. Esta operación resulta especialmente útil cuando se necesita:
+ Eliminar todos los datos asociados a un paciente
+ Cumpla con las solicitudes de eliminación de datos de los pacientes
+ Gestione el ciclo de vida de los datos
+ Realice una limpieza exhaustiva de los registros de los pacientes
## De uso
La `$purge` operación se puede invocar en los recursos del paciente:
```
POST [base]/Patient/[ID]/$purge?deleteAuditEvent=true
```
## Parameters
| Parámetro | Tipo | Obligatorio/a | Predeterminado | Description (Descripción) |
| --- | --- | --- | --- | --- |
| deleteAuditEvent | booleano | No | false | Si es verdadero, elimina los eventos de auditoría asociados |
| \$1since | cadena | No | Hora de creación del almacén de datos | Cuando se introduce, selecciona la hora límite de inicio para buscar los recursos en función de su hora de última modificación. No se puede usar ni al principio ni al final |
| start | cadena | No | Hora de creación del almacén de datos | Cuando se introduce, selecciona la hora límite para buscar los recursos en función de su hora de última modificación. Se puede usar con el final |
| end | cadena | No | Tiempo de presentación de trabajos | Cuando se introduce, selecciona la hora límite de finalización para buscar los recursos en función de su hora de última modificación |
## Ejemplos
**Solicitud de ejemplo**
```
POST [base]/Patient/example-patient/$purge?deleteAuditEvent=true
```
**Respuesta de ejemplo**
```
{
"resourceType": "OperationOutcome",
"id": "purge-job",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Purge job started successfully. Job ID: 12345678-1234-1234-1234-123456789012"
}
]
}
```
## Estado del trabajo
Para comprobar el estado de un trabajo de purga:
```
GET [base]/$purge/[jobId]
```
La operación devuelve información sobre el estado del trabajo:
```
{
"datastoreId": "36622996b1fcecb7e12ee2ee085308d3",
"jobId": "3dd1c7a5b6c0ef8c110f566eb87e2ef9",
"status": "COMPLETED",
"submittedTime": "2025-10-31T18:43:21.822Z"
}
```
## Comportamiento
La `$purge` operación:
1. Procesa de forma asíncrona para gestionar varios recursos
1. Mantiene las transacciones ACID para garantizar la integridad de los datos
1. Proporciona un seguimiento del estado de los trabajos con recuentos de eliminaciones de recursos
1. Elimina permanentemente todos los recursos del compartimento del paciente
1. Incluye un registro de auditoría completo de las actividades de eliminación
1. Soporta la eliminación selectiva de eventos de auditoría
## Registro de auditoría
La `$purge` operación se registra como Inicio FHIRBulk DeleteJob y Descripción FHIRBulk DeleteJob con información detallada sobre la operación.
## Limitaciones
+ Los recursos purgados no aparecerán en las respuestas de búsqueda
+ Es posible que los recursos que se están purgando estén inaccesibles temporalmente durante el procesamiento
+ Todos los recursos del compartimento del paciente se retiran permanentemente
# `$questionnaire-package`Operación FHIR para HealthLake
La `$questionnaire-package` operación recupera un paquete completo que contiene un cuestionario del FHIR y todas sus dependencias necesarias para procesar y procesar el cuestionario. Esta operación implementa la [Guía de implementación de las plantillas y reglas de documentación (DTR) de Da Vinci](https://hl7.org/fhir/us/davinci-dtr/OperationDefinition-questionnaire-package.html), que permite la representación dinámica de los formularios para los requisitos de documentación en los flujos de trabajo de atención médica.
## Funcionamiento
+ **Solicitud**: Usted envía los parámetros que identifican los cuestionarios necesarios, junto con la cobertura y el contexto del pedido
+ **Recuperar**: HealthLake recopila el cuestionario y todas las dependencias (ValueSetsbibliotecas de CQL, etc.)
+ **Paquete**: Todos los recursos se agrupan en un formato estandarizado
+ **Responda**: recibirá un paquete completo listo para su procesamiento y recopilación de datos
**Casos de uso**
+ **Documentación de autorización previa**: recopile la información clínica requerida para las solicitudes de autorización previa
+ **Requisitos de cobertura**: reúna la documentación necesaria para cumplir con los requisitos de cobertura del pagador
+ **Clinical Data Exchange**: estructura los datos clínicos para enviarlos a los pagadores
+ **Formularios dinámicos**: renderice cuestionarios con datos de pacientes previamente rellenados y lógica condicional
## Punto de conexión de la API
```
POST /datastore/{datastoreId}/r4/Questionnaire/$questionnaire-package
Content-Type: application/fhir+json
```
## Parámetros de solicitud
### Parámetros de entrada
El cuerpo de la solicitud debe contener un recurso de parámetros del FHIR con los siguientes parámetros:
| Parámetro | Tipo | Cardinalidad | Description (Descripción) |
| --- | --- | --- | --- |
| coverage | Cobertura | 1.. \$1 (Obligatorio) | Recurso (s) de cobertura para determinar el miembro y cobertura de la documentación |
| questionnaire | canonical | 0.. \$1 | URL canónicas de cuestionarios específicos a devolver (pueden incluir una versión) |
| order | Recurso | 0.. \$1 | Solicite recursos (DeviceRequest,, ServiceRequest MedicationRequest, Encuentro, Cita) para establecer el contexto |
| changedSince | dateTime | 0.1 | Si está presente, devuelva solo los recursos modificados después de esta marca de tiempo |
### Reglas de validación de parámetros
**Debe proporcionarse al menos UNO de los siguientes datos** (además de los obligatorios`coverage`):
+ Uno o más `questionnaire` canónicos URLs
+ Uno o más recursos `order`
**Combinaciones de solicitudes válidas:**
+ `coverage` \$1 `questionnaire`
+ `coverage` \$1 `order`
+ `coverage` \$1 `questionnaire` \$1 `order`
## Ejemplo de solicitud
```
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 las respuestas
### Respuesta correcta (200 OK)
La operación devuelve un recurso de parámetros FHIR que contiene uno o más **Package Bundles**. Cada Package Bundle incluye:
| Tipo de entrada | Cardinalidad | Description (Descripción) |
| --- | --- | --- |
| Cuestionario | 1 | El cuestionario que se va a entregar |
| QuestionnaireResponse | 0.1.. | Respuesta rellenada previamente o completada parcialmente (si corresponde) |
| Library | 0.. \$1 | Bibliotecas CQL que contienen lógica condicional y previa a la población |
| ValueSet | 0.. \$1 | Ampliado ValueSets (para opciones de respuesta con menos de 40 expansiones) |
**Example Ejemplo de respuesta**
```
{
"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"
}
}]
}
}
]
}
```
## Flujo de trabajo operativo
**¿Cómo HealthLake procesa su solicitud**
Cuando llames`$questionnaire-package`, HealthLake realiza los siguientes pasos:
1. **Identifique al paciente y al pagador**: extraiga el paciente y la organización de seguros a partir de su `coverage` parámetro.
1. **Encuentre el cuestionario correcto**:
+ **Con `questionnaire`** **el parámetro**: usa la URL canónica que proporcionaste
+ **Con** el `order` **parámetro**: Coincide con el código del pedido (CPT/HCPCS/LOINC) y el pagador para encontrar el cuestionario correspondiente
1. **Reunir dependencias**: recupera automáticamente todo lo necesario para procesar el cuestionario:
+ **Bibliotecas CQL**: lógica para preguntas condicionales y previas al rellenado
+ **ValueSets**- Opciones de respuesta (se amplían automáticamente si hay menos de 40 opciones)
+ **QuestionnaireResponse**- Cualquier respuesta existente, en curso o completada
1. **Package todo junto**:
+ Agrupa todos los recursos (cada recurso se incluye solo una vez)
+ Filtra por `changedSince` marca de tiempo si se proporciona
+ Añade advertencias en `Outcome` caso de que falte algún recurso
**Resultado**: un paquete completo e independiente listo para renderizarse.
## Respuestas de error
### 400: solicitud maligna
Se devuelve cuando la validación de la solicitud falla.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "required",
"details": {
"text": "At least one of 'questionnaire' or 'order' must be provided along with 'coverage'"
}
}]
}
```
### 4.2.4 Dependencia fallida
Se devuelve cuando no se puede recuperar un recurso dependiente.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "warning",
"code": "not-found",
"details": {
"text": "Referenced Library 'http://example.org/fhir/Library/missing-library' could not be retrieved"
}
}]
}
```
### 401 sin autorización
Se devuelve cuando faltan credenciales de autenticación o no son válidas.
### 403: prohibido
Se devuelve cuando el usuario autenticado no tiene permiso para acceder a los recursos solicitados.
### 406 No es aceptable
Se devuelve cuando no se puede proporcionar el tipo de contenido solicitado.
### Conflicto, 409
Se devuelve cuando hay un conflicto de versiones o de simultaneidad.
### 410 Se ha ido
Se devuelve cuando el recurso solicitado se ha eliminado permanentemente.
### 429 Demasiadas solicitudes
Se devuelve cuando se superan los límites de velocidad.
### 500 Error de servidor interno
Se devuelve cuando se produce un error inesperado en el servidor.
### 501 No implementado
Se devuelve cuando la operación solicitada aún no está implementada.
## Reglas de validación
### Validación de entradas
+ `coverage`el parámetro es **obligatorio** (1.. \$1 cardinalidad)
+ `order`Debe proporcionarse al menos uno de `questionnaire` ellos
+ Todos los recursos de cobertura deben ser recursos válidos del FHIR
+ Todos los recursos del pedido deben ser recursos válidos del FHIR
+ Canonical URLs debe tener el formato correcto
+ `changedSince`debe ser un DateTime ISO 8601 válido
### QuestionnaireResponse validación
+ `status`debe ser apropiado (`in-progress`,`completed`,`amended`)
+ La estructura debe coincidir con el cuestionario al que se hace referencia
+ `basedOn`debe hacer referencia a los recursos del pedido válidos
+ `subject`debe hacer referencia a recursos válidos para pacientes
### Deduplicación de recursos
+ Cada recurso aparece solo una vez en el paquete
+ Excepción: es posible que se incluyan diferentes versiones del mismo recurso
+ Los recursos se identifican por su URL y versión canónicas
## Especificaciones de rendimiento
| Métrica | Especificación |
| --- | --- |
| Límite de recuento de recursos | 500 recursos por paquete |
| Límite de tamaño del paquete | 5 MB como máximo |
## Permisos necesarios
Para utilizar la `$questionnaire-package` operación, asegúrese de que su función de IAM tenga:
+ `healthlake:QuestionnairePackage`- Para convocar a la operación
+ `healthlake:ReadResource`- Para recuperar el cuestionario y los recursos dependientes
+ `healthlake:SearchWithPost`- Para buscar recursos QuestionnaireResponse y recursos relacionados
**SMART en FHIR Scopes**
**Alcances mínimos requeridos:**
+ **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 importantes sobre la implementación
### Estrategia de recuperación de recursos
**Prioridad de identificación del cuestionario:**
+ **URL canónica** (si se proporciona el `questionnaire` parámetro): prioridad máxima
+ **Análisis de pedidos** (si se proporciona `order` el parámetro):
+ Haga coincidir los códigos de pedido (CPT, HCPCS, LOINC) con las pólizas médicas del pagador
+ Use el pagador de cobertura para filtrar los cuestionarios específicos del pagador
+ Tenga en cuenta los códigos de motivo para obtener un contexto adicional
### Resolución de dependencias
**Bibliotecas CQL:**
+ Recuperado a través de la `cqf-library` extensión sobre los recursos del cuestionario
+ Busca de forma recursiva las bibliotecas dependientes mediante `Library.relatedArtifact` el tipo `depends-on`
+ Todas las dependencias de la biblioteca están incluidas en el paquete
**ValueSets:**
+ Se expanden automáticamente si contienen menos de 40 conceptos
+ ValueSets Los más grandes se incluyen sin expansión
+ ValueSets Se incluyen los recursos referenciados tanto en el cuestionario como en la biblioteca
### QuestionnaireResponse prepoblación
La operación puede devolver un QuestionnaireResponse con datos rellenados previamente cuando:
+ Se encuentra una respuesta ya finalizada o en curso
+ La lógica CQL de las bibliotecas asociadas puede extraer datos de los registros de los pacientes
+ La respuesta está vinculada al pedido y la cobertura pertinentes
**Criterios de búsqueda para QuestionnaireResponse:**
| Parámetro de búsqueda | Ruta FHIR | Description (Descripción) |
| --- | --- | --- |
| based-on | QuestionnaireResponse.basedOn | Enlaces a ServiceRequest o CarePlan |
| patient | QuestionnaireResponse.subject | El paciente que es el sujeto |
| questionnaire | QuestionnaireResponse.questionnaire | El cuestionario que se está respondiendo |
### Se modificó el filtrado de recursos
Cuando se proporciona el `changedSince` parámetro:
+ Solo se incluyen los recursos modificados **después** de la marca de tiempo especificada
+ Si ningún recurso ha cambiado, regresa `200 OK` con un paquete vacío
+ Útil para actualizaciones incrementales y estrategias de almacenamiento en caché
+ La comparación de marcas de tiempo utiliza el campo de recursos `meta.lastUpdated`
### Múltiples paquetes
La operación puede devolver **varios Package Bundles** cuando:
+ Se solicitan varios cuestionarios a través de Canonical URLs
+ Los pedidos múltiples requieren cuestionarios diferentes
+ Se aplican diferentes versiones del mismo cuestionario
Cada Package Bundle es autónomo y cuenta con todas las dependencias necesarias.
## Casos de uso comunes
### Caso de uso 1: documentación de autorización previa
**Escenario**: un proveedor debe recopilar la documentación necesaria para obtener una autorización previa para la oxigenoterapia domiciliaria.
```
{
"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**: devuelve un paquete con el cuestionario de oxigenoterapia, rellenado previamente con los datos vitales del paciente y los códigos de diagnóstico del EHR.
### Caso de uso 2: recupere una versión específica del cuestionario
**Escenario**: un proveedor necesita una versión específica de un cuestionario para cumplir con los requisitos.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Coverage resource */ }
},
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/dme-request|3.1.0"
}
]
}
```
**Resultado**: devuelve exactamente la versión 3.1.0 del cuestionario de solicitud del DME con todas las dependencias.
### Caso de uso 3: comprobar si hay actualizaciones
**Escenario**: un proveedor quiere comprobar si algún recurso del cuestionario se ha actualizado desde la última consulta.
```
{
"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**: devuelve solo los recursos que se hayan modificado después del 1 de marzo de 2024 o un paquete vacío si no ha cambiado nada.
### Caso de uso 4: pedidos múltiples
**Escenario**: un proveedor envía varias solicitudes de servicio que pueden requerir cuestionarios diferentes.
```
{
"resourceType": "Parameters",
"parameter": [
{
"name": "coverage",
"resource": { /* Coverage resource */ }
},
{
"name": "order",
"resource": { /* ServiceRequest for imaging */ }
},
{
"name": "order",
"resource": { /* ServiceRequest for DME */ }
}
]
}
```
**Resultado**: devuelve varios Package Bundles, uno para cada cuestionario aplicable.
## Integración con otros Da Vinci IGs
### Descubrimiento de requisitos de cobertura (CRD)
**Integración del flujo de trabajo:**
+ El proveedor solicita un servicio en su registro electrónico electrónico
+ El CRD Hook se dispara, comprobando los requisitos de cobertura
+ El pagador responde indicando que necesita documentación
+ El proveedor llama `$questionnaire-package` para recuperar el formulario de documentación
+ El proveedor completa el cuestionario
+ La documentación se envía a través del PAS o CDex
### Soporte de autorización previa (PAS)
**Integración del flujo de trabajo:**
+ Se utiliza `$questionnaire-package` para recuperar los requisitos de documentación
+ Complete el formulario QuestionnaireResponse con los datos clínicos requeridos
+ Envíe la autorización previa `Claim/$submit` junto con la cumplimentada QuestionnaireResponse
+ Compruebe el estado utilizando `Claim/$inquire`
### Intercambio de datos clínicos (CDex)
**Integración del flujo de trabajo:**
+ El pagador solicita documentación adicional para una reclamación
+ El proveedor utiliza `$questionnaire-package` para recuperar el formulario de recopilación de datos estructurados
+ El proveedor completa el QuestionnaireResponse
+ La documentación se envía al pagador a través del flujo de trabajo CDex adjunto
## Guía para solucionar problemas
### Problema: No se devolvió el cuestionario
**Posibles causas:**
+ La URL canónica no coincide con ningún cuestionario del almacén de datos
+ El código del pedido no se corresponde con ningún cuestionario de la política médica del pagador
+ El pagador de la cobertura no tiene cuestionarios asociados
**Soluciones:**
+ Verifica que la URL canónica sea correcta y que el cuestionario exista
+ Comprueba que los códigos de pedido (CPT/HCPCS) estén correctamente especificados
+ Confirme que la organización pagadora tenga configurados los cuestionarios
### Problema: Faltan dependencias en el paquete
**Posibles causas:**
+ Biblioteca a la que se hace referencia o ValueSet no existe en el almacén de datos
+ Las referencias a la biblioteca están rotas o son incorrectas
+ ValueSet la expansión ha fallado
**Soluciones:**
+ Compruebe el `Outcome` parámetro para ver si hay advertencias sobre la falta de recursos
+ Compruebe que todos los recursos a los que se hace referencia existan en el banco de datos
+ Asegúrese de que ValueSet URLs son correctos y se pueden resolver
### Problema: Empty Package con ChangedSince
**Posibles causas:**
+ Este es el comportamiento esperado: no se ha modificado ningún recurso desde la marca de tiempo especificada
**Soluciones:**
+ Utilice la versión en caché del paquete
+ Elimine `changedSince` el parámetro para recuperar el paquete completo
### Problema: QuestionnaireResponse no se ha rellenado previamente
**Posibles causas:**
+ No se QuestionnaireResponse encontró ningún elemento existente
+ La lógica de la biblioteca CQL no pudo extraer los datos necesarios
+ Faltan datos del paciente o están incompletos
**Soluciones:**
+ Esto es de esperar: no todos los cuestionarios tienen una lógica previa a la población
+ Compruebe que los datos del paciente existan en el almacén de datos
+ Revise la lógica de la biblioteca CQL para conocer los requisitos de extracción de datos
## Prácticas recomendadas
### 1. Utilice Canonical URLs con las versiones
Especifique siempre los números de versión cuando solicite cuestionarios específicos:
```
{
"name": "questionnaire",
"valueCanonical": "http://example.org/fhir/Questionnaire/dme|2.1.0"
}
```
**Por qué**: Garantiza la coherencia y evita cambios inesperados cuando se actualizan los cuestionarios.
### 2. Aproveche los cambios desde entonces para mejorar el rendimiento
Para los cuestionarios a los que se accede con frecuencia, utilícelos `changedSince` para minimizar la transferencia de datos:
```
{
"name": "changedSince",
"valueDateTime": "2024-03-10T15:30:00Z"
}
```
**Por qué**: reduce la latencia y el uso de ancho de banda al recuperar solo los recursos actualizados.
### 3. Incluya información completa sobre la cobertura
Proporcione detalles de cobertura completos para garantizar la correcta selección del cuestionario:
```
{
"name": "coverage",
"resource": {
"resourceType": "Coverage",
"beneficiary": { "reference": "Patient/123" },
"payor": [{ "reference": "Organization/payer-abc" }],
"class": [{ /* Group/plan information */ }]
}
}
```
**Por qué**: Ayuda a HealthLake identificar los cuestionarios y requisitos específicos del pagador.
## Operaciones de relacionadas
+ `Claim/$submit`- Presente las solicitudes de autorización previa con la documentación completa
+ `Claim/$inquire`- Verificar el estado de las autorizaciones previas presentadas
+ `ValueSet/$expand`- Ampliar ValueSets para ver las opciones de respuesta
# `$submit`Operación FHIR para HealthLake
La `$submit` operación le permite enviar electrónicamente solicitudes de autorización previa a los pagadores para su aprobación. Esta operación implementa la [Guía de implementación de Da Vinci Prior Authorization Support (PAS)](https://hl7.org/fhir/us/davinci-pas/), que proporciona un flujo de trabajo estandarizado basado en el FHIR para la presentación de autorizaciones previas.
## Funcionamiento
+ **Enviar**: envía un paquete FHIR que contiene su solicitud de autorización previa y los datos clínicos de respaldo
+ **Validar**: HealthLake valida la presentación según los requisitos del PAS
+ **Persistir**: todos los recursos se almacenan en su almacén HealthLake de datos
+ **Responder**: recibirá una respuesta inmediata con el estado de «en cola»
+ **Proceso**: el pagador procesa la decisión de autorización de forma asíncrona
## Punto de conexión de la API
```
POST /datastore/{datastoreId}/r4/Claim/$submit
Content-Type: application/fhir+json
```
## Estructura de la solicitud
### Requisitos del paquete
Su solicitud debe ser un recurso del paquete FHIR con:
+ **Tipo de paquete: debe ser** `"collection"`
+ **Bundle.entry****: debe contener exactamente un recurso de reclamación con** `use = "preauthorization"`
+ **Recursos de referencia**: todos los recursos a los que se hace referencia en la reclamación deben incluirse en el paquete
### Recursos necesarios de
| Recurso | Cardinalidad | Perfil | Description (Descripción) |
| --- | --- | --- | --- |
| Reclamación | 1 | Reclamación PAS | La solicitud de autorización previa |
| Paciente | 1 | Paciente PAS | Información demográfica del paciente |
| Organización (aseguradora) | 1 | Aseguradora PAS | Compañía de seguros |
| Organización (proveedor) | 1 | Solicitante del PAS | Proveedor de atención médica que presenta la solicitud |
| Cobertura | 1 o más | Cobertura PAS | Detalles de la cobertura del seguro |
### Recursos opcionales
| Recurso | Cardinalidad | Perfil | Description (Descripción) |
| --- | --- | --- | --- |
| Práctico | 0 o más | Profesional de PAS | Profesionales de la salud |
| PractitionerRole | 0 o más | PAS PractitionerRole | Funciones de los profesionales |
| ServiceRequest | 0 o más | PAS ServiceRequest | Servicios médicos solicitados |
| DeviceRequest | 0 o más | PAS DeviceRequest | Dispositivos médicos solicitados |
| MedicationRequest | 0 o más | PAS MedicationRequest | Medicamentos solicitados |
| DocumentReference | 0 o más | PAS DocumentReference | Documentación clínica de apoyo |
## Ejemplo de solicitud
```
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 las respuestas
### Respuesta satisfactoria (200 OK)
Recibirá un paquete de respuesta del PAS que contiene:
+ **ClaimResponse**con `outcome: "queued"` y `status: "active"`
+ Todos los recursos originales de su solicitud
+ Marca de tiempo que confirma la recepción
```
{
"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"
}
}]
}
```
## Respuestas de error
### 400: solicitud maligna
Se devuelve cuando el formato de la solicitud no es válido o está mal formado.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "invalid",
"diagnostics": "The provided payload was invalid and could not be parsed correctly."
}]
}
```
### Condición previa con error, 412
Se devuelve cuando ya se ha presentado la misma solicitud de autorización previa (se ha detectado un envío duplicado).
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "processing",
"diagnostics": "PreAuth Claim already exists"
}]
}
```
**Idempotencia**
La `$submit` operación es idempotente. Si se envía la misma solicitud varias veces, no se duplicarán las solicitudes de autorización previa. En su lugar, recibirás un mensaje de error 412 que te indicará que lo utilices `$inquire` para comprobar el estado del envío original.
### 4.2.2 Entidad inprocesable
Se devuelve cuando la validación del FHIR falla.
```
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "required",
"diagnostics": "Bundle contains more than one preauthorization claim"
}]
}
```
## Reglas de validación
HealthLake realiza una validación exhaustiva de su envío:
### Validación del paquete
+ Debe ajustarse al perfil del paquete de solicitud de PAS
+ `Bundle.type`debe ser `"collection"`
+ Puede contener varios recursos de reclamación
+ Sin embargo, debe contener exactamente un recurso de reclamación con uso previo a la autorización
+ Y este recurso de reclamación debe ser la primera entrada del paquete
+ Todos los recursos a los que se hace referencia deben incluirse en el paquete
### Validación de la reclamación
+ Debe ajustarse al perfil de reclamación del PAS
+ `Claim.use`debe ser `"preauthorization"`
+ Campos obligatorios:`patient`,`insurer`,`provider`,`created`, `priority`
+ Los identificadores comerciales deben estar presentes y ser válidos
### Validación de recursos
+ Todos los recursos deben ajustarse a sus respectivos perfiles de PAS
+ Deben estar presentes los recursos de apoyo necesarios (paciente, cobertura, organización)
+ Las referencias cruzadas deben ser válidas y poder resolverse dentro del paquete
## Especificaciones de rendimiento
| Métrica | Especificación |
| --- | --- |
| Límite de tamaño del paquete | 5 MB como máximo |
| Límite de recuento de recursos | 500 recursos por paquete |
## Permisos necesarios
Para usar la `$submit` operación, se puede usar AWS Sigv4 o SMART en FHIR:
+ Asegúrese de que su función de IAM tenga: `healthlake:SubmitPreAuthClaim` - Llamar a la operación
**SMART en los osciloscopios FHIR**
**Alcances mínimos requeridos:**
+ **SMART v1**: `user/Claim.write & .write`
+ **SMART v2**: `user/Claim.c & .c or system/*.*`
## Notas importantes sobre la implementación
### Persistencia de los recursos
+ Todas las entradas del paquete se conservan como recursos FHIR individuales en su almacén de datos
+ Las suministradas por el cliente se conservan cuando se proporcionan IDs
+ El historial de versiones se mantiene con fines de auditoría
+ La detección de duplicados evita conflictos de recursos
### Comportamiento de procesamiento
+ Cada envío válido da como resultado exactamente uno ClaimResponse con `"queued"` resultado
+ Los envíos no válidos devuelven 400 o 422 códigos de estado con información de error detallada
+ Los errores del sistema devuelven los códigos de estado 5xx correspondientes
+ Todos los envíos aprobados devuelven el estado 200 con un estado pendiente ClaimResponse
### Requisitos del paquete
+ `Bundle.entry.fullUrl`los valores deben estar en formato REST URLs o en `"urn:uuid:[guid]"` formato
+ Todos los envíos GUIDs deben ser únicos (excepto las mismas instancias de recursos)
+ Los recursos a los que se hace referencia deben existir en el paquete o ser resolubles
## Operaciones de relacionadas
+ `Claim/$inquire`- Consulta el estado de una solicitud de autorización previa presentada
+ `Patient/$everything`- Recupere datos completos de los pacientes para utilizarlos en el contexto de la autorización previa
# Validación de los recursos del FHIR con `$validate`
AWS HealthLake ahora admite la `$validate` operación con los recursos del FHIR, lo que le permite validar un recurso según la especificación del FHIR y comprobar su conformidad con un perfil específico o una definición de recurso base sin realizar ninguna operación de almacenamiento. Esta operación resulta especialmente útil cuando se necesita:
+ Validar los requisitos de conformidad con el CMS del FHIR
+ Pruebe los recursos antes de usarlos en producción
+ Proporcione comentarios de validación en tiempo real a medida que los usuarios editan los datos clínicos
+ Reduzca el envío de datos no válidos para crear y actualizar APIs
## De uso
La `$validate` operación se puede invocar en los recursos del FHIR mediante los métodos POST:
**Operaciones admitidas**
```
POST [base]/[type]/[id]/$validate
POST [base]/[type]/$validate
```
## Cargas útiles compatibles
**Recurso de parámetros**
HealthLake admite los siguientes `$validate` parámetros del FHIR:
| Parámetro | Tipo | Obligatorio | Description (Descripción) |
| --- | --- | --- | --- |
| resource | Recurso | Sí | El recurso que se va a validar |
| profile | canonical | No | URL canónica del perfil con el que se va a realizar la validación |
| mode | code | No | Modo de validación:create, o update |
**Recurso directo con parámetros de consulta**
| Parámetro | Tipo | Obligatorio | Description (Descripción) |
| --- | --- | --- | --- |
| profile | canonical | No | URL canónica del perfil con el que realizar la validación |
| mode | code | No | Modo de validación:create, o update |
## Ejemplos
**Solicitud POST de recurso con carga útil de ID y 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"
}
]
}
```
**Solicitud POST de carga útil sobre el tipo de recurso y los 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"
}
]
}
```
**Solicitud POST de recurso con ID y carga útil de recurso directa**
```
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"
}
```
**Solicitud POST de tipo de recurso y carga útil directa del 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"
}
```
**Respuesta de ejemplo**
La operación devuelve un OperationOutcome recurso con los resultados de la validación:
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Validation successful"
}
]
}
```
**Ejemplo de respuesta con errores de validación**
```
{
"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"
]
}
]
}
```
## Comportamiento
La `$validate` operación:
1. Valida el recurso según la especificación del FHIR y la definición del recurso base
1. Comprueba la conformidad con los perfiles especificados cuando se proporciona el parámetro `profile`
1. Valida en función del modo (`create`o) especificado `update`
1. Devuelve los resultados de la validación detallados, incluidos los errores, las advertencias y los mensajes informativos
1. No realiza ninguna operación de almacenamiento, solo de validación
1. Devuelve HTTP 200 OK cuando se puede realizar la validación, independientemente de si se han detectado problemas de validación
## Modos de validación
+ **crear**: valida el recurso como si se estuviera creando (recurso nuevo)
+ **actualizar**: valida el recurso como si se estuviera actualizando (recurso existente)
## Gestión de errores
La operación devuelve:
+ 200 OK: La validación se realizó correctamente (independientemente del resultado de la validación)
+ 400 Solicitud errónea: el formato o los parámetros de la solicitud no son válidos
+ 404 No se encontró: no se encontró el tipo de recurso o perfil
Para obtener más información sobre la especificación de la `$validate` operación, consulte la documentación de [recursos `$validate` del FHIR R4](https://www.hl7.org/fhir/R4/operation-resource-validate.html).
# Referencia de cumplimiento para AWS HealthLake
AWS HealthLake proporciona funciones diseñadas para ayudarlo a rastrear y reportar el uso de las API de acuerdo con los requisitos de interoperabilidad de los CMS (Centros de Servicios de Medicare y Medicaid). Estas funciones le permiten clasificar las transacciones de la API según las categorías exigidas por el CMS y recopilar automáticamente las métricas de uso para elaborar informes de conformidad.
**Comprenda sus responsabilidades de cumplimiento**
El uso AWS HealthLake y sus puntos finales de interoperabilidad del CMS **no son suficientes por sí solos** para lograr la conformidad con los CMS. Su responsabilidad incluye:
Asigne correctamente los flujos de trabajo de sus API a los puntos finales de la categoría de CMS correspondiente en función de sus casos de uso específicos y sus obligaciones reglamentarias
Implementar los controles de autenticación y autorización adecuados que cumplan con los requisitos de los CMS
Garantizar que sus recursos e intercambios de datos del FHIR cumplan con las normas y guías de implementación aplicables de la CMS
Configurar y monitorear las CloudWatch métricas para respaldar sus necesidades de informes de cumplimiento
Comprenda qué reglas de CMS se aplican a su organización e implemente los controles técnicos y operativos adecuados
AWS HealthLake proporciona la infraestructura y las herramientas necesarias para respaldar sus esfuerzos de cumplimiento, pero debe utilizar estas funciones de forma adecuada en función de sus requisitos reglamentarios específicos. El simple hecho de dirigir las llamadas a la API a través de estos puntos finales no hace que su aplicación cumpla automáticamente con las normas de los CMS.
**Topics**
+ [CMS](reference-compliance-cms.md)
# Características de conformidad con los CMS
AWS HealthLake ofrece funciones que le ayudan a cumplir los requisitos de interoperabilidad y conformidad de los CMS (Centros de Servicios de Medicare y Medicaid). Estas funciones le permiten realizar un seguimiento del uso de las API por categoría de CMS y, posteriormente, elaborar informes sobre las métricas de uso con fines de cumplimiento.
**Topics**
+ [Puntos finales de interoperabilidad de los CMS](#cms-interoperability-endpoints)
+ [CloudWatch Métricas mejoradas para el cumplimiento de los CMS](#cms-cloudwatch-metrics)
## Puntos finales de interoperabilidad de los CMS
### Descripción general de
HealthLake proporciona cuatro puntos finales de interoperabilidad del CMS que corresponden a las categorías de API exigidas por el CMS. La URL base subyacente de su almacén de HealthLake datos no cambia. Estos puntos de enlace simplemente proporcionan una forma de categorizar y realizar un seguimiento de las llamadas a la API con el fin de generar informes sobre los CMS.
### Finalidad
El objetivo principal de estos puntos finales de interoperabilidad es permitir a los clientes:
+ **Realice un seguimiento sencillo de** las transacciones de API por categoría de CMS
+ **Informe automáticamente** las métricas de uso para garantizar el cumplimiento de los CMS
+ **Mantenga** los flujos de trabajo del FHIR existentes con cambios mínimos
Todas las llamadas a la API funcionan de forma idéntica tanto si se utiliza el punto final de interoperabilidad como el punto final estándar del FHIR; la única diferencia es la forma en que se clasifican las transacciones en las métricas. CloudWatch
### Puntos finales de interoperabilidad de CMS compatibles
| Categoría CMS | Punto final de interoperabilidad | Ejemplo de uso |
| --- | --- | --- |
| Acceso de pacientes | /patientaccess/v2/r4 | baseURL/patientaccess/v2/r4/Patient/123 |
| Acceso a proveedores | /provideraccess/v2/r4 | baseURL/provideraccess/v2/r4/Observation?patient=123 |
| De pagador a pagador | /payertopayerdx/v2/r4 | baseURL/payertopayerdx/v2/r4/Practitioner/456 |
| Servicio de autenticación previa | /priorauthservice/v2/r4 | baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789 |
### Cómo funcionan los puntos finales de interoperabilidad
**Llamada a la HealthLake API estándar:**
```
baseURL/resourceType/[id]
baseURL/resourceType?[parameters]
```
**Con CMS Interoperability Endpoint:**
```
baseURL/interoperability-endpoint/resourceType/[id]
baseURL/interoperability-endpoint/resourceType?[parameters]
```
La ruta del punto final de interoperabilidad simplemente se inserta entre la URL base y el tipo de recurso. Todo lo que sigue a la ruta del punto final de interoperabilidad permanece exactamente igual que las llamadas a la API actuales.
### Ejemplos de uso
#### Ejemplo 1: API de acceso para pacientes
**Llamada a la API actual (aún funciona):**
```
curl -X GET \
https://healthlake.us-east-1.amazonaws.com/datastore/abc123/r4/Patient/123 \
-H "Authorization: Bearer " \
-H "Content-Type: application/fhir+json"
```
**Con el punto final de interoperabilidad de Patient Access (para el seguimiento de los CMS):**
```
curl -X GET \
https://healthlake.us-east-1.amazonaws.com/datastore/abc123/patientaccess/v2/r4/Patient/123 \
-H "Authorization: Bearer " \
-H "Content-Type: application/fhir+json"
```
**Puntos clave:**
+ La URL base sigue siendo: `https://healthlake.us-east-1.amazonaws.com/datastore/abc123`
+ Se ha insertado el punto final de interoperabilidad: `/patientaccess/v2/r4`
+ La ruta de recursos no ha cambiado: `/Patient/123`
+ **Ambas llamadas devuelven respuestas idénticas**
+ La llamada al punto final de interoperabilidad se rastrea automáticamente en `URIType=patient-access` CloudWatch
+ Las operaciones POST, PUT, PATCH y DELETE funcionan de forma idéntica.
+ El cuerpo de la solicitud permanece inalterado.
### Referencia de traducción del punto final
| Punto final de interoperabilidad | Se traduce como | Categoría CMS |
| --- | --- | --- |
| baseURL/patientaccess/v2/r4/Patient | baseURL/r4/Patient | Acceso para pacientes |
| baseURL/provideraccess/v2/r4/Observation | baseURL/r4/Observation | Acceso a proveedores |
| baseURL/payertopayerdx/v2/r4/Practitioner/456 | baseURL/r4/Practitioner/456 | Data Exchange de pagador a pagador |
| baseURL/priorauthservice/v2/r4/ExplanationOfBenefit?patient=789 | baseURL/r4/ExplanationOfBenefit?patient=789 | Autorización previa |
### Notas importantes
+ **Sin diferencia funcional**: los puntos finales de interoperabilidad y los puntos finales estándar del FHIR arrojan respuestas idénticas y admiten operaciones idénticas
+ **URL base sin cambios**: el punto final de su almacén de HealthLake datos sigue siendo el mismo
+ **Integración sencilla**: inserte la ruta del punto final de interoperabilidad entre la URL base y el tipo de recurso
+ **Seguimiento automático**: CloudWatch las métricas clasifican automáticamente las llamadas según el punto final de interoperabilidad utilizado
+ **Compatible con versiones anteriores**: las llamadas a la API existentes sin puntos de enlace de interoperabilidad siguen funcionando con normalidad
## CloudWatch Métricas mejoradas para el cumplimiento de los CMS
### Descripción general de
Cuando utiliza los puntos finales de interoperabilidad del CMS, emite HealthLake automáticamente CloudWatch métricas mejoradas con dimensiones adicionales para cumplir con los requisitos de presentación de informes de los CMS. **Estas métricas rastrean el uso de la API por identidad de la persona que llama, aplicación y tipos de URI específicos del CMS sin necesidad de realizar ninguna configuración adicional.**
### Funcionamiento
Cuando realizas una llamada a la API mediante un punto final de interoperabilidad:
```
# This call...
curl https://healthlake.us-east-1.amazonaws.com/datastore/abc123/patientaccess/v2/r4/Patient/123
# Automatically generates metrics with:
# - URIType: "patient-access"
# - Sub: extracted from your bearer token (SMART on FHIR datastores only)
# - ClientId: extracted from your bearer token (SMART on FHIR datastores only)
# - Plus all standard dimensions (DatastoreId, Operation, etc.)
```
**No se necesita ningún código o configuración adicional.** Simplemente utilice los puntos finales de interoperabilidad y las métricas mejoradas se capturarán automáticamente.
**nota**
En el caso de los almacenes de datos del FHIR que no son inteligentes, la `URIType` dimensión se sigue capturando, lo que permite realizar un seguimiento del uso de las API por categoría de CMS. `ClientId`Las dimensiones `Sub` y solo están disponibles cuando se utiliza la autenticación SMART on FHIR con fichas portadoras que contengan estas afirmaciones.
### Nuevas dimensiones métricas
Además de las dimensiones existentes (`DatastoreId`,,`Operation`)`DatastoreType`, las siguientes dimensiones se añaden automáticamente cuando se utilizan puntos finales de interoperabilidad:
| Dimensión | Description (Descripción) | Valores de ejemplo | origen |
| --- | --- | --- | --- |
| URIType | Categoría de conformidad con los CMS | patient-access, provider-access, payer-to-payer, prior-authorization | Se determina automáticamente a partir de la ruta del punto final de interoperabilidad |
| Sub | Identidad de la persona que llama | Identificador de usuario/entidad | Extraído de la afirmación del token del portador sub |
| ClientId | Identificador de la aplicación | portal\$1app, ehr\$1system | Extraído de la afirmación del portador del token client\$1id |
### Métricas disponibles
Todas las HealthLake métricas existentes ahora incluyen las dimensiones adicionales cuando se utilizan los puntos finales de interoperabilidad:
+ **CallCount**- Número total de llamadas a la API
+ **Latencia**: tiempo de respuesta de la API en milisegundos
+ **UserErrors**- Recuento de 4 xx errores de cliente
+ **SystemErrors**- Recuento de 5xx errores en el servidor
+ **Throttles**: número de solicitudes restringidas
+ **SuccessfulRequests**- Número de llamadas a la API que se han realizado correctamente
### Consultando métricas en CloudWatch
#### CloudWatch Ejemplo de consulta de Insights
**Consulta todas las llamadas a la API Patient Access por aplicación:**
```
SELECT SUM(CallCount)
FROM "AWS/HealthLake"
WHERE DatastoreId = '75c1cf9b0d71cd38fec8f7fb317c4c1a'
AND URIType = 'patient-access'
GROUP BY ClientId
```
# Referencia de soporte para AWS HealthLake
El siguiente material de referencia de apoyo está disponible para AWS HealthLake.
**nota**
Todas HealthLake las acciones y tipos de datos nativos se describen en una referencia independiente. Para obtener más información, consulte la [Referencia de la API de *AWS HealthLake *](https://docs.aws.amazon.com/healthlake/latest/APIReference/).
**Topics**
+ [Cuotas y puntos de conexión](reference-healthlake-endpoints-quotas.md)
+ [Tipos de datos precargados](reference-healthlake-preloaded-data-types.md)
+ [Proyectos de ejemplo](reference-healthlake-sample-projects.md)
+ [Resolución de problemas](reference-healthlake-troubleshooting.md)
+ [Trabajando con AWS SDKs](sdk-general-information-section.md)
# AWS HealthLake puntos finales y cuotas
Los siguientes temas contienen información sobre los puntos finales y las cuotas del AWS HealthLake servicio.
**Topics**
+ [Puntos de conexión de servicio](#reference-healthlake-endpoints)
+ [Cuotas de servicio](#reference-healthlake-quotas)
## Puntos de conexión de servicio
Los puntos de conexión de servicio son URL que identifican un host y un puerto como puntos de entrada de un servicio web. Cada solicitud de servicio web contiene un punto de enlace. La mayoría de AWS los servicios proporcionan puntos de conexión para regiones específicas a fin de permitir una conectividad más rápida. En la siguiente tabla se enumeran los puntos finales del servicio para. AWS HealthLake
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/healthlake/latest/devguide/reference-healthlake-endpoints-quotas.html)
## Cuotas de servicio
Las cuotas de servicio se definen como el valor máximo de los recursos, acciones y elementos de su AWS cuenta.
**nota**
Puede solicitar aumentos de cuota para cuotas ajustables mediante [Service Quotas](https://console.aws.amazon.com/servicequotas/). Para obtener más información, consulte [Solicitud de aumento de cuota](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) en la *Guía del usuario de Service Quotas*.
La velocidad de la API de sincronización y escritura aumenta proporcionalmente con el tamaño de la carga útil, y cada incremento de 1 KB consume capacidad adicional (por ejemplo, una carga útil de 4 KB utiliza 4 veces la capacidad de escritura). Si se configura el `x-amz-fhir-history-consistency-level` encabezado opcional para `strong` duplicar el consumo de capacidad de escritura por recurso.
Los recursos de los paquetes siguen los read/write límites estándar basados en un tamaño de carga útil de 1 KB. Las *transacciones* de tipo lote consumen el doble de capacidad de escritura que las de tipo *lote*, lo que significa que los paquetes de *lotes* pueden procesar el doble de recursos por segundo que los paquetes de transacciones.
En la siguiente tabla se muestran las cuotas predeterminadas para. AWS HealthLake
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/healthlake/latest/devguide/reference-healthlake-endpoints-quotas.html)
# Tipos de datos precargados de Synthea para HealthLake
HealthLake solo admite SYNTHEA como tipo de datos precargado. [Synthea es un](https://synthetichealth.github.io/synthea/) generador sintético de pacientes que `Patient` modela la historia clínica. Está alojado en un repositorio Git de código abierto que permite generar un recurso `Bundle` compatible con FHIR R4 HealthLake para que los usuarios puedan probar modelos sin utilizar datos reales de pacientes.
Los siguientes tipos de recursos están disponibles en los almacenes de datos precargados. HealthLake Para obtener más información sobre la precarga de HealthLake los almacenes de datos con datos de Synthea, consulte. [Creación de un almacén HealthLake de datos](managing-data-stores-create.md)
**nota**
Para ver una lista completa de los recursos del FHIR R4 HealthLake compatibles, consulte. [Tipos de recursos compatibles con FHIR R4 para HealthLake](reference-fhir-resource-types.md)
**Tipos de recursos del FHIR de síntesis compatibles con HealthLake**
| | |
| --- |--- |
| AllergyIntolerance | Ubicación |
| CarePlan | MedicationAdministration |
| CareTeam | MedicationRequest |
| Reclamación | Observación |
| Condición | Organización |
| Dispositivo | Paciente |
| DiagnosticReport | Práctico |
| Encuentro | PractitionerRole |
| ExplanationofBenefit | Procedimiento |
| ImagingStudy | Procedencia |
| Inmunización | |
# AWS HealthLake proyectos de muestra
Para profundizar en el análisis, puede utilizarlos HealthLake con otros AWS servicios, como se muestra en los siguientes ejemplos de entradas de blog.
**HealthLake análisis integrados**
+ [Aplicaciones de salud de la población con AWS HealthLake — Parte 1: Análisis y monitoreo con Amazon Quick](https://aws.amazon.com/blogs/machine-learning/population-health-applications-with-amazon-healthlake-part-1-analytics-and-monitoring-using-amazon-quicksight/).
+ [Creación de modelos predictivos de enfermedades con Amazon SageMaker AI con datos AWS HealthLake normalizados](https://aws.amazon.com/blogs/machine-learning/building-predictive-disease-models-using-amazon-sagemaker-with-amazon-healthlake-normalized-data/).
+ [Cree una búsqueda cognitiva y un gráfico de conocimientos sobre salud mediante los servicios 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 monitoreo de eventos**
+ [ EventBridge Integración de Amazon con AWS HealthLake](https://aws.amazon.com/blogs/industries/amazon-eventbridge-integration-for-aws-healthlake/).
# Solución de problemas AWS HealthLake
En los temas siguientes se proporcionan consejos para solucionar los errores y problemas que puedan surgir al utilizar la HealthLake consola AWS CLI AWS SDKs, o. Si encuentra un problema que no aparece en esta sección, utilice el botón **Enviar comentarios** en la barra lateral derecha de esta página para informarlo.
**Topics**
+ [Acciones de almacenamiento de datos](#troubleshooting-data-store)
+ [Acciones de importación](#troubleshooting-import)
+ [FHIR APIs](#troubleshooting-fhir-apis)
+ [Integraciones de PNL](#troubleshooting-nlp-integrations)
+ [Integraciones de SQL](#troubleshooting-sql-integrations)
## Acciones de almacenamiento de datos
**Problema:** *cuando intento crear un banco de HealthLake datos, aparece el siguiente error:*
```
AccessDeniedException: Insufficient Lake Formation permission(s): Required Database on Catalog
```
El 14 de noviembre de 2022, HealthLake actualicé los permisos de IAM necesarios para crear un nuevo banco de datos. Para obtener más información, consulte [Configure el usuario o rol de IAM que desee utilizar HealthLake (administrador de IAM)](getting-started-setting-up.md#setting-up-configure-iam).
**Problema:** *Al crear un banco de HealthLake datos mediante el AWS SDKs, el estado de creación del banco de datos devuelve un estado de excepción o desconocido*.
Actualice su AWS SDK a la última versión si sus llamadas `DescribeFHIRDatastore` o las de la `ListFHIRDatastores` API devuelven una excepción o un estado desconocido del almacén de datos.
## Acciones de importación
**Problema:** *¿Puedo seguir utilizándolos HealthLake si mis datos no están en formato FHIR R4*?
Solo los datos con formato FHIR R4 se pueden importar a un almacén de datos. HealthLake [Para ver una lista de socios que pueden ayudar a transformar los datos de salud existentes al formato R4 del FHIR, consulte Socios.AWS HealthLake](https://docs.aws.amazon.com/healthlake/partners/)
**Problema:** *¿Por qué falló mi trabajo de importación del FHIR*?
Si la importación se realiza correctamente, se generará una carpeta con los resultados (registro de salida) en `.ndjson` formato; sin embargo, es posible que no se puedan importar registros individuales. Cuando esto suceda, se generará una segunda `FAILURE` carpeta con un manifiesto de los registros que no se pudieron importar. Para obtener más información, consulte [Importación de datos del FHIR con AWS HealthLake](importing-fhir-data.md).
Para analizar por qué ha fallado un trabajo de importación, utilice la `DescribeFHIRImportJob` API para analizar el JobProperties. Se recomienda lo siguiente:
+ Si el estado es `FAILED` y aparece un mensaje, los errores están relacionados con parámetros del trabajo, como el tamaño de los datos de entrada o el número de archivos de entrada, que superan HealthLake las cuotas.
+ Si el estado del trabajo de importación es`COMPLETED_WITH_ERRORS`, consulte el archivo de manifiesto para obtener información sobre los archivos que no se importaron correctamente. `manifest.json`
+ Si el estado del trabajo de importación es `FAILED` y no hay ningún mensaje, vaya a la ubicación de salida del trabajo para acceder al archivo de manifiesto`manifest.json`.
Para cada archivo de entrada, hay un archivo de salida con un nombre de archivo de entrada para cualquier recurso que no se pueda importar. Las respuestas contienen el número de línea (LineID) correspondiente a la ubicación de los datos de entrada, el objeto de respuesta del FHIR (UpdateResourceResponse) y el código de estado (StatusCode) de la respuesta.
Un ejemplo de archivo de salida podría ser similar al siguiente:
```
{"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}
```
El ejemplo anterior muestra que hubo errores en las líneas 3, 4, 7, 9 y 15 de las líneas de entrada correspondientes del archivo de entrada. Para cada una de esas líneas, las explicaciones son las siguientes:
+ En la línea 3, la respuesta explica lo que `resourceType` se proporciona en la línea 3 del archivo de entrada no es válido.
+ En la línea 5, la respuesta explica que hay un error de validación del FHIR en la línea 5 del archivo de entrada.
+ En la línea 7, la respuesta explica que hay un problema de validación y `resourceId` se proporciona como entrada.
+ En la línea 9, la respuesta explica que el archivo de entrada debe contener un identificador de recurso válido.
+ En la línea 15, la respuesta del archivo de entrada es que el archivo no está en un formato JSON válido.
## FHIR APIs
**Asunto:** *¿Cómo puedo implementar la autorización para el RESTful APIs FHIR*?
Determine el que se [Estrategia de autorización del almacén de datos](getting-started-concepts.md#concept-data-store-authorization-strategy) va a utilizar.
Para crear una autorización SigV4 mediante el AWS SDK para Python (Boto3), cree un script similar al siguiente ejemplo.
```
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 qué recibo `AccessDenied` errores al utilizar el FHIR RESTful APIs para un almacén de datos cifrado con una clave KMS gestionada por el cliente*?
Para que un usuario o rol pueda acceder a un almacén de datos, se requieren permisos tanto para las claves administradas por el cliente como para las políticas de IAM. El usuario debe tener los permisos de IAM necesarios para utilizar una clave gestionada por el cliente. Si un usuario revoca o retira una concesión que daba HealthLake permiso para usar la clave de KMS administrada por el cliente, HealthLake devolverá un `AccessDenied` error.
HealthLake debe tener el permiso para acceder a los datos de los clientes, cifrar los nuevos recursos del FHIR importados a un almacén de datos y descifrar los recursos del FHIR cuando se soliciten. [Para obtener más información, consulte Solución de problemas de permisos. AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/policy-evaluation.html)
**Problema:** *una operación de la `POST` API del FHIR que HealthLake utiliza un documento de 10 MB devuelve el `413 Request Entity Too Large`* error.
AWS HealthLake tiene un límite sincrónico de 5 MB para crear y actualizar la API para evitar el aumento de las latencias y los tiempos de espera. Puede ingerir documentos de gran tamaño, de hasta 164 MB, utilizando el tipo de `Binary` recurso que utilice la API de importación masiva.
## Integraciones de PNL
**Problema:** *¿Cómo activo la función HealthLake de procesamiento de lenguaje natural integrada*?
A partir del 14 de noviembre de 2022, el comportamiento predeterminado de HealthLake los almacenes de datos cambió.
**Almacenes de datos actuales**: todos los almacenes de HealthLake datos actuales dejarán de utilizar el procesamiento del lenguaje natural (NLP) en los recursos codificados en base64`DocumentReference`. Esto significa que `DocumentReference` los nuevos recursos no se analizarán mediante la PNL y no se generarán nuevos recursos a partir del texto del tipo de recurso. `DocumentReference` En el caso de `DocumentReference` los recursos existentes, los datos y los recursos generados mediante la PNL permanecen, pero no se actualizarán después del 20 de febrero de 2023.
**Nuevos almacenes de datos**: HealthLake los almacenes de datos creados después del 20 de febrero de 2023 *no* procesarán el lenguaje natural (NLP) en recursos codificados en `DocumentReference` base64.
Para activar la integración de la HealthLake PNL, cree un caso de soporte utilizando. [AWS Support Center Console](https://console.aws.amazon.com/support/home#/) Para crear tu caso, inicia sesión en tu y Cuenta de AWS, a continuación, selecciona **Crear caso**. Para obtener más información sobre la creación de un caso y la gestión de casos, consulte [Creación de casos de soporte y gestión de casos](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) en la *Guía del Soporte usuario*.
**Problema:** *> ¿Cómo puedo encontrar `DocumentReference` recursos que no puedan procesarse con la PNL integrada*?
Si un `DocumentReference` recurso no es válido, HealthLake proporciona una extensión que indica un error de validación en lugar de incluirlo en el resultado de la PNL médica integrada. **Para encontrar `DocumentReference` los recursos que provocaron un error de validación durante el procesamiento de la PNL, puede utilizar la `search` función FHIR con la clave HealthLake de búsqueda **cm-decoration-status**y el valor de búsqueda VALIDATION\$1ERROR.** Esta búsqueda mostrará una lista de todos los `DocumentReference` recursos que provocaron errores de validación, junto con un mensaje de error que describe la naturaleza del error. La estructura del campo de extensión en los `DocumentReference` recursos con errores de validación se parecerá a la del siguiente ejemplo.
```
"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**
También `VALIDATION_ERROR` puede ocurrir si la decoración de la PNL crea más de 10 000 objetos anidados. Cuando esto sucede, el documento debe dividirse en documentos más pequeños antes de procesarlo.
## Integraciones de SQL
**Problema:** *¿Por qué obtengo un Lake Formation `permissions error: lakeformation:PutDataLakeSettings` al añadir un nuevo administrador de lagos de datos?*
Si su usuario o rol de IAM contiene la política `AWSLakeFormationDataAdmin` AWS administrada, no podrá añadir nuevos administradores de lagos de datos. Aparecerá un error que contiene lo siguiente:
```
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
```
La política AWS gestionada `AdministratorAccess` es necesaria para añadir un usuario o rol de IAM como administrador AWS del lago de datos de Lake Formation. Si su usuario o rol de IAM también lo contiene, `AWSLakeFormationDataAdmin` la acción fallará. La política `AWSLakeFormationDataAdmin` AWS gestionada contiene una denegación explícita de la operación de la API AWS Lake Formation,`PutDataLakeSetting`. Incluso los administradores con acceso total al AWS uso de la política `AdministratorAccess` administrada pueden estar limitados por la `AWSLakeFormationDataAdmin` política.
**Problema:** *¿Cómo puedo migrar un almacén de HealthLake datos existente para usar la integración de Amazon Athena SQL*?
HealthLake los almacenes de datos creados antes del 14 de noviembre de 2022 son funcionales, pero no se pueden consultar en Athena mediante SQL. Para consultar un banco de datos preexistente con Athena, primero debe migrarlo a un banco de datos nuevo.
**Para migrar sus HealthLake datos a un nuevo banco de datos**
1. Cree un nuevo banco de datos.
1. Exporte los datos del depósito preexistente a un bucket de Amazon S3.
1. Importe los datos al nuevo almacén de datos desde el bucket de Amazon S3.
**nota**
La exportación de datos a un bucket de Amazon S3 conlleva un coste adicional. El cargo adicional depende del tamaño de los datos que exporte.
**Problema:** *Al crear un nuevo HealthLake banco de datos para la integración con SQL, el estado del banco de datos no cambia`Creating`.*
Si intenta crear un nuevo banco de HealthLake datos y su estado no cambia desde **Crear**, debe actualizar Athena para usar el. AWS Glue Data Catalog Para obtener más información, consulte [Actualización al catálogo de datos de AWS Glue step-by-step](https://docs.aws.amazon.com/athena/latest/ug/glue-upgrade.html) en la Guía del *usuario de Amazon Athena*.
Después de actualizar correctamente el AWS Glue Data Catalog, puede crear un almacén de HealthLake datos.
Para eliminar un almacén de HealthLake datos antiguo, cree un caso de soporte utilizando [AWS Support Center Console](https://console.aws.amazon.com/support/home#/). Para crear su caso, inicie sesión en su y Cuenta de AWS, a continuación, seleccione **Crear caso**. Para obtener más información, consulte [Creación de casos de soporte y administración de casos](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) en la *Guía del Soporte usuario*.
**Problema:** *la consola Athena no funciona después de importar datos a un nuevo HealthLake * almacén de datos
Después de importar los datos a un nuevo banco de HealthLake datos, es posible que los datos no estén disponibles para su uso inmediato. Esto es para dar tiempo a que los datos se ingieran en las tablas de Apache Iceberg. Inténtelo de nuevo más tarde.
**Problema:** *¿Cómo puedo conectar los resultados de búsqueda de Athena con otros AWS servicios*?
Al compartir los resultados de búsqueda de Athena con otros AWS servicios, pueden producirse problemas al utilizarlos `json_extract[1]` como parte de una consulta de búsqueda de SQL. Para solucionar este problema, debe actualizar a`CATVAR`.
Este problema puede producirse al intentar **crear** resultados guardados, una **tabla** (estática) o una **vista** (dinámica).
# HealthLake Utilización con un AWS SDK
AWS Los kits de desarrollo de software (SDKs) están disponibles para muchos lenguajes de programación populares. Cada SDK proporciona una API, ejemplos de código y documentación que facilitan a los desarrolladores la creación de aplicaciones en su lenguaje preferido.
| Documentación de SDK | Ejemplos de código |
| --- | --- |
| [AWS SDK para C\$1\$1](https://docs.aws.amazon.com/sdk-for-cpp) | [AWS SDK para C\$1\$1 ejemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp) |
| [AWS CLI](https://docs.aws.amazon.com/cli) | [AWS CLI ejemplos 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 ejemplos 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 ejemplos 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 ejemplos 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 ejemplos 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 ejemplos 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 ejemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/php) |
| [Herramientas de AWS para PowerShell](https://docs.aws.amazon.com/powershell) | [Herramientas de AWS para PowerShell ejemplos 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) ejemplos 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 ejemplos 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 ejemplos 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 ejemplos 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 ejemplos de código](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/swift) |
**Ejemplo de disponibilidad**
¿No encuentra lo que necesita? Solicite un ejemplo de código a través del enlace de **Enviar comentarios** que se encuentra al final de esta página.