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.
# Administrar los recursos del FHIR en AWS HealthLake
Utilice las interacciones de la RESTful API R4 del FHIR para gestionar los recursos del FHIR en un almacén de datos. HealthLake En las siguientes secciones se describen todas las interacciones de la RESTful API R4 del FHIR HealthLake compatibles y disponibles para la gestión de recursos del FHIR. Para obtener información sobre las capacidades del almacén de HealthLake datos y las partes de la especificación del FHIR compatibles, consulte. [Declaración de capacidad del FHIR R4 para AWS HealthLake](reference-fhir-capability-statement.md)
**nota**
Las interacciones del FHIR que se enumeran en este capítulo están diseñadas de conformidad con el estándar R4 del HL7 FHIR para el intercambio de datos de atención médica. Como son representaciones de los servicios del HL7 FHIR, no se ofrecen a través de y. AWS CLI AWS SDKs Para obtener más información, consulte la [RESTful API](https://hl7.org/fhir/R4/http.html) en la documentación de la API **R4 RESTful del FHIR**.
En la siguiente tabla se enumeran las interacciones del FHIR R4 compatibles con. AWS HealthLake Para obtener información sobre los *tipos de recursos* del FHIR compatibles HealthLake, consulte. [Tipos de recurso](reference-fhir-resource-types.md)
**Las interacciones FHIR R4 son compatibles con AWS HealthLake**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/healthlake/latest/devguide/managing-fhir-resources.html)
**Topics**
+ [Creación de un recurso FHIR](managing-fhir-resources-create.md)
+ [Lectura de un recurso del FHIR](managing-fhir-resources-read.md)
+ [Lectura del historial de recursos del FHIR](managing-fhir-resources-read-history.md)
+ [Actualización de un recurso del FHIR](managing-fhir-resources-update.md)
+ [Modificación de recursos con la operación PATCH](managing-fhir-resources-patch.md)
+ [Agrupación de recursos del FHIR](managing-fhir-resources-bundle.md)
+ [Eliminar un recurso del FHIR](managing-fhir-resources-delete.md)
+ [Idempotencia y concurrencia](managing-fhir-resources-idempotency.md)
# Creación de un recurso FHIR
La `create` interacción del FHIR crea un nuevo recurso del FHIR en un HealthLake almacén de datos. Para obtener información adicional, consulte la documentación de la [https://hl7.org/fhir/R4/http.html#create](https://hl7.org/fhir/R4/http.html#create)API ** RESTful R4 del FHIR**.
**Para crear un recurso del FHIR**
1. HealthLake `region`Recopila y `datastoreId` valora. Para obtener más información, consulte [Obtención de propiedades de los almacenes de datos](managing-data-stores-describe.md).
1. Determine el tipo de FHIR `Resource` que desea crear. Para obtener más información, consulte [Tipos de recurso](reference-fhir-resource-types.md).
1. Cree una URL para la solicitud utilizando los valores recopilados para HealthLake `region` y`datastoreId`. Incluya también el `Resource` tipo FHIR que desee crear. Para ver la ruta URL completa en el siguiente ejemplo, desplázate sobre el botón **Copiar**.
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource
```
1. Cree un cuerpo JSON para la solicitud y especifique los datos del FHIR del nuevo recurso. Para este procedimiento, utilizamos un `Patient` recurso del FHIR, así que guarde el archivo como. `create-patient.json`
```
{
"resourceType": "Patient",
"identifier": [
{
"system": "urn:oid:1.2.36.146.595.217.0.1",
"value": "12345"
}
],
"name": [
{
"family": "Silva",
"given": [
"Ana",
"Carolina"
]
}
],
"gender": "female",
"birthDate": "1992-02-10"
}
```
1. Envíe la solicitud . La `create` interacción del FHIR utiliza una `POST` solicitud con la [versión 4 de la AWS firma](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) o SMART previa autorización del FHIR. En los siguientes ejemplos se crea un `Patient` recurso del FHIR HealthLake utilizando curl o la consola. HealthLake Para ver un ejemplo completo, desplázate sobre el botón **Copiar**.
------
#### [ SigV4 ]
Autorización SigV4
```
curl --request POST \
'https://healthlake.region.amazonaws.com/datastore/datastore-id/r4/Patient' \
--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' \
--data @create-patient.json
```
------
#### [ SMART on FHIR ]
Ejemplo de autorización SMART on FHIR para el 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
La persona que llama puede asignar permisos en la lambda de autorización. Para obtener más información, consulte [OAuth osciloscopios 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
#### [ AWS Console ]
**nota**
La HealthLake consola solo admite la autorización [AWS SiGv4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html).
1. Inicie sesión en la página [Ejecutar consultas](https://console.aws.amazon.com/healthlake/home#/crud) de la HealthLake consola.
2. En la sección de **configuración de consultas**, realice las siguientes selecciones.
+ **ID de almacén de datos**: elija un ID de almacén de datos para generar una cadena de consulta.
+ **Tipo de consulta**: elija`Create`.
+ **Tipo de recurso**: elija el [tipo de recurso](reference-fhir-resource-types.md) FHIR que desee crear.
+ **Cuerpo de la solicitud**: cree un cuerpo JSON para la solicitud y especifique los datos del FHIR del nuevo recurso.
3. Elija **Ejecutar consulta**.
------
**Configurar el nivel de validación para la creación de recursos**
Al crear un recurso FHIR, puede especificar opcionalmente un encabezado `x-amzn-healthlake-fhir-validation-level` HTTP para configurar un nivel de validación para el recurso. AWS HealthLake actualmente admite los siguientes niveles de validación:
+ `strict`: Los recursos se validan según el elemento de perfil del recurso o según la especificación R4 si no hay ningún perfil presente. Este es el nivel de validación predeterminado para AWS HealthLake.
+ `structure-only`: Los recursos se validan con el R4 e ignoran los perfiles a los que se hace referencia.
+ `minimal`: Los recursos se validan mínimamente, ignorando ciertas reglas de R4. Los recursos que no superen las comprobaciones de estructura requeridas se search/analytics actualizarán para incluir una advertencia para la auditoría.
Los recursos creados con el nivel de validación mínimo pueden incorporarse a un almacén de datos a pesar de no pasar la validación necesaria para la indexación de las búsquedas. En este caso, los recursos se actualizarán para incluir una extensión específica de Healthlake para documentar dichos errores:
```
{
"url": "http://healthlake.amazonaws.com/fhir/StructureDefinition/validation-issue",
"valueString": "{\"resourceType\":\"OperationOutcome\",\"issue\":[{\"severity\":\"error\",\"code\":\"processing\",\"details\":{\"text\":\"FHIR resource in payload failed FHIR validation rules.\"},\"diagnostics\":\"FHIR resource in payload failed FHIR validation rules.\"}]}"
}
```
Además, se incluirá el siguiente encabezado de respuesta HTTP con el valor «true»:
```
x-amzn-healthlake-validation-issues : true
```
**nota**
Es posible que los datos ingresados que tengan un formato incorrecto según la especificación R4 no se puedan buscar como se esperaba si se presentan estos errores.
# Lectura de un recurso del FHIR
La `read` interacción del FHIR lee el estado actual de un recurso en un almacén de HealthLake datos. Para obtener información adicional, consulte la documentación de [https://hl7.org/fhir/R4/http.html#read](https://hl7.org/fhir/R4/http.html#read)la API **R4 RESTful del FHIR**.
**Para leer un recurso del FHIR**
1. Colecciona HealthLake `region` y `datastoreId` valora. Para obtener más información, consulte [Obtención de propiedades de los almacenes de datos](managing-data-stores-describe.md).
1. Determine el tipo de FHIR `Resource` para leer y recopilar el `id` valor asociado. Para obtener más información, consulte [Tipos de recurso](reference-fhir-resource-types.md).
1. Cree una URL para la solicitud utilizando los valores recopilados para HealthLake `region` y`datastoreId`. Incluya también el `Resource` tipo FHIR y su correspondiente`id`. Para ver la ruta URL completa en el siguiente ejemplo, desplázate sobre el botón **Copiar**.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. Envíe la solicitud . La `read` interacción del FHIR utiliza una `GET` solicitud con la [versión 4 de la AWS firma](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) o SMART con la autorización del FHIR. En el siguiente `curl` ejemplo, se lee el estado actual de un recurso del FHIR `Patient` en. HealthLake Para ver el ejemplo completo, desplázate sobre el botón **Copiar**.
------
#### [ SigV4 ]
Autorización SigV4
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id' \
--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'
```
------
#### [ SMART on FHIR ]
Ejemplo de autorización SMART on FHIR para el 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
La persona que llama puede asignar permisos en la lambda de autorización. Para obtener más información, consulte [OAuth osciloscopios 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
#### [ AWS Console ]
1. Inicie sesión en la página [Ejecutar consultas](https://console.aws.amazon.com/healthlake/home#/crud) de la HealthLake consola.
2. En la sección de **configuración de consultas**, realice las siguientes selecciones.
+ **ID de almacén de datos**: elija un ID de almacén de datos para generar una cadena de consulta.
+ **Tipo de consulta**: elija`Read`.
+ **Tipo de recurso**: elija el [tipo de recurso](reference-fhir-resource-types.md) FHIR que desee leer.
+ **ID de recurso**: introduzca el ID de recurso del FHIR.
3. Elija **Ejecutar consulta**.
------
# Lectura del historial de recursos del FHIR
La `history` interacción del FHIR recupera el historial de un recurso del FHIR en particular en un almacén de datos. HealthLake Con esta interacción, puede determinar cómo ha cambiado el contenido de un recurso del FHIR a lo largo del tiempo. También resulta útil, en coordinación con los registros de auditoría, para ver el estado de un recurso antes y después de la modificación. El FHIR `create` interactúa `update` y da `delete` como resultado una versión histórica del recurso que se va a guardar. Para obtener información adicional, consulte la documentación de [https://hl7.org/fhir/R4/http.html#history](https://hl7.org/fhir/R4/http.html#history)la API **R4 RESTful del FHIR**.
**nota**
Puede optar por no utilizar tipos de recursos `history` específicos del FHIR. Para excluirse, cree un caso utilizando [AWS Support Center Console](https://console.aws.amazon.com/support/home#/). Para crear tu caso, inicia sesión en tu cuenta Cuenta de AWS y selecciona **Crear caso**.
**Para leer el historial de recursos del FHIR**
1. HealthLake `region`Recopila y `datastoreId` valora. Para obtener más información, consulte [Obtención de propiedades de los almacenes de datos](managing-data-stores-describe.md).
1. Determine el tipo de FHIR `Resource` para leer y recopilar el `id` valor asociado. Para obtener más información, consulte [Tipos de recurso](reference-fhir-resource-types.md).
1. Cree una URL para la solicitud utilizando los valores recopilados para HealthLake `region` y`datastoreId`. Incluya también el `Resource` tipo de FHIR, sus parámetros de búsqueda asociados `id` y opcionales. Para ver la ruta URL completa en el siguiente ejemplo, desplázate sobre el botón **Copiar**.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id/_history{?[parameters]}
```
**HealthLake parámetros de búsqueda compatibles para la interacción FHIR `history`**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/healthlake/latest/devguide/managing-fhir-resources-read-history.html)
1. Envíe la solicitud . La `history` interacción del FHIR utiliza una `GET` solicitud con la [versión 4 de la AWS firma](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) o SMART previa autorización del FHIR. En el siguiente `curl` ejemplo, se utiliza el parámetro de `_count` búsqueda para devolver 100 resultados de búsqueda históricos por página para un recurso del FHIR `Patient` en. HealthLake Para ver el ejemplo completo, desplázate sobre el botón **Copiar**.
------
#### [ SigV4 ]
Autorización SigV4
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastore-id/r4/Patient/id/_history?_count=100' \
--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'
```
------
#### [ SMART on FHIR ]
Ejemplo de autorización SMART on FHIR para el 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
La persona que llama puede asignar permisos en la lambda de autorización. Para obtener más información, consulte [OAuth osciloscopios 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
El contenido devuelto de una `history` interacción está contenido en un recurso FHIR`Bundle`, con el tipo establecido en. `history` Contiene el historial de versiones especificado, ordenado en último lugar por las versiones más antiguas, e incluye los recursos eliminados. Para obtener más información, consulte [https://hl7.org/fhir/R4/bundle.html](https://hl7.org/fhir/R4/bundle.html)la documentación del **FHIR R4**.
## Lectura del historial de recursos del FHIR específico de cada versión
La `vread` interacción del FHIR realiza una lectura específica de la versión de un recurso en un almacén de datos. HealthLake Con esta interacción, puede ver el contenido de un recurso del FHIR tal como estaba en un momento determinado del pasado.
**nota**
Si utiliza la `history` interacción del FHIR *sin* `vread` ella, HealthLake siempre devuelve la última versión de los metadatos del recurso.
HealthLake declara que admite el control de versiones [https://hl7.org/fhir/R4/capabilitystatement-definitions.html#CapabilityStatement.rest.resource.versioning](https://hl7.org/fhir/R4/capabilitystatement-definitions.html#CapabilityStatement.rest.resource.versioning)para cada recurso compatible. Todos los almacenes de HealthLake datos incluyen `Resource.meta.versionId` (`vid`) en todos los recursos.
Cuando `history` la interacción FHIR está habilitada (de forma predeterminada para los almacenes de datos creados después del 25 de octubre de 2024 o cuando se solicita para los almacenes de datos más antiguos), la `Bundle` respuesta los incluye `vid` como parte del elemento. [https://hl7.org/fhir/R4/bundle-definitions.html#Bundle.entry.response.location](https://hl7.org/fhir/R4/bundle-definitions.html#Bundle.entry.response.location) En el siguiente ejemplo, se `vid` muestra como un número. `1` Para ver el ejemplo completo, consulta Example [Bundle/Bundle-Response](https://build.fhir.org/bundle-response.json.html) (JSON).
```
"response" : {
"status" : "201 Created",
"location" : "Patient/12423/_history/1",
...}
```
**Para leer el historial de recursos del FHIR específico de cada versión**
1. HealthLake `region`Recopila y valora. `datastoreId` Para obtener más información, consulte [Obtención de propiedades de los almacenes de datos](managing-data-stores-describe.md).
1. Determine el `Resource` tipo de FHIR que se va a leer y recopilar `vid` los valores `id` y valores asociados. Para obtener más información, consulte [Tipos de recurso](reference-fhir-resource-types.md).
1. Cree una URL para la solicitud utilizando los valores recopilados para el HealthLake FHIR. Para ver la ruta URL completa en el siguiente ejemplo, desplázate sobre el botón **Copiar**.
```
GET https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id/_history/vid
```
1. Envíe la solicitud . La `history` interacción del FHIR utiliza una `GET` solicitud con la [versión 4 de la AWS firma](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) o SMART con la autorización del FHIR. La siguiente `vread` interacción devuelve una sola instancia con el contenido especificado para el `Patient` recurso de la FHIR para la versión de los metadatos del recurso especificada por la. `vid` Para ver la ruta URL completa en el siguiente ejemplo, desplázate sobre el botón **Copiar**.
------
#### [ SigV4 ]
Autorización SigV4
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastore-id/r4/Patient/id/_history/vid' \
--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'
```
------
#### [ SMART on FHIR ]
Ejemplo de autorización SMART on FHIR para el 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
La persona que llama puede asignar permisos en la lambda de autorización. Para obtener más información, consulte [OAuth osciloscopios 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
# Actualización de un recurso del FHIR
La `update` interacción del FHIR crea una nueva versión actual para un recurso existente o crea una versión inicial si aún no existe ningún recurso para ese recurso. `id` Para obtener información adicional, consulte la documentación de [https://hl7.org/fhir/R4/http.html#update](https://hl7.org/fhir/R4/http.html#update)la API **R4 RESTful del FHIR**.
**Para actualizar un recurso del FHIR**
1. HealthLake `region`Recopila y `datastoreId` valora. Para obtener más información, consulte [Obtención de propiedades de los almacenes de datos](managing-data-stores-describe.md).
1. Determine el tipo de `Resource` FHIR que desea actualizar y recopile el `id` valor asociado. Para obtener más información, consulte [Tipos de recurso](reference-fhir-resource-types.md).
1. Cree una URL para la solicitud utilizando los valores recopilados para HealthLake `region` y`datastoreId`. Incluya también el `Resource` tipo FHIR y su correspondiente`id`. Para ver la ruta URL completa en el siguiente ejemplo, desplázate sobre el botón **Copiar**.
```
PUT https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. Cree un `JSON` cuerpo para la solicitud, especificando las actualizaciones de datos del FHIR que se van a realizar. Para este procedimiento, guarde el archivo como`update-patient.json`.
```
{
"id": "2de04858-ba65-44c1-8af1-f2fe69a977d9",
"resourceType": "Patient",
"active": true,
"name": [
{
"use": "official",
"family": "Doe",
"given": [
"Jane"
]
},
{
"use": "usual",
"given": [
"Jane"
]
}
],
"gender": "female",
"birthDate": "1985-12-31"
}
```
1. Envíe la solicitud . La `update` interacción con el FHIR utiliza una `PUT` solicitud con la [versión 4 de AWS Signature](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) o SMART previa autorización del FHIR. En el siguiente `curl` ejemplo, se actualiza un `Patient` recurso en. HealthLake Para ver el ejemplo completo, desplázate sobre el botón **Copiar**.
------
#### [ SigV4 ]
Autorización SigV4
```
curl --request PUT \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id' \
--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' \
--data @update-patient.json
```
Su solicitud devolverá un código de estado `200` HTTP si se *actualiza* un recurso existente o un código de estado `201` HTTP si se crea un recurso nuevo.
------
#### [ SMART on FHIR ]
Ejemplo de autorización SMART on FHIR para el tipo [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)de datos.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
La persona que llama puede asignar permisos en la lambda de autorización. Para obtener más información, consulte [OAuth osciloscopios 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
#### [ AWS Console ]
1. Inicie sesión en la página [Ejecutar consultas](https://console.aws.amazon.com/healthlake/home#/crud) de la HealthLake consola.
2. En la sección de **configuración de consultas**, realice las siguientes selecciones.
+ **ID de almacén de datos**: elija un ID de almacén de datos para generar una cadena de consulta.
+ **Tipo de consulta**: elija`Update (PUT)`.
+ **Tipo de recurso**: elija el [tipo de recurso](reference-fhir-resource-types.md) FHIR que desee actualizar o crear.
+ **Cuerpo de la solicitud**: cree un cuerpo JSON para la solicitud y especifique los datos del FHIR con los que se va a actualizar el recurso.
3. Elija **Ejecutar consulta**.
------
## Actualización de los recursos del FHIR en función de las condiciones
La actualización condicional permite actualizar un recurso existente en función de algunos criterios de búsqueda de identificación, en lugar de hacerlo mediante el FHIR `id` lógico. Cuando el servidor procesa la actualización, realiza una búsqueda utilizando sus capacidades de búsqueda estándar para el tipo de recurso, con el objetivo de resolver una única lógica `id` para la solicitud.
La acción que realice el servidor depende del número de coincidencias que encuentre:
+ **No hay coincidencias, no `id` se proporciona en el cuerpo de la solicitud**: el servidor crea el recurso FHIR.
+ **No hay coincidencias, `id` se ha proporcionado y el recurso aún no existe con el `id`**: el servidor trata la interacción como una interacción entre actualizar y crear.
+ **No hay coincidencias, `id` se ha proporcionado y ya existe**: el servidor rechaza la actualización con un `409 Conflict` error.
+ **Una coincidencia, no `id` se proporcionó ningún recurso O (recurso `id` proporcionado y coincide con el recurso encontrado)**: el servidor realiza la actualización con el recurso coincidente como se indica anteriormente, donde, si el recurso se actualizó, el servidor DEVOLVERÁ un`200 OK`.
+ **Una coincidencia, recurso `id` proporcionado pero no coincide con el recurso encontrado**: el servidor devuelve un `409 Conflict` error que indica que la especificación del identificador de cliente era un problema, preferiblemente con un `OperationOutcome`
+ **Varias coincidencias**: el servidor devuelve un `412 Precondition Failed` error que indica que los criterios del cliente no fueron lo suficientemente selectivos, preferiblemente con un OperationOutcome
En el siguiente ejemplo, se actualiza un `Patient` recurso cuyo nombre es peter, su fecha de nacimiento es el 1 de enero de 2000 y su número de teléfono es 1234567890.
```
PUT https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?name=peter&birthdate=2000-01-01&phone=1234567890
```
## Configurar el nivel de validación para las actualizaciones de recursos
Al actualizar un recurso del FHIR, puede especificar opcionalmente un encabezado `x-amzn-healthlake-fhir-validation-level` HTTP para configurar un nivel de validación para el recurso. AWS HealthLake actualmente admite los siguientes niveles de validación:
+ `strict`: Los recursos se validan según el elemento de perfil del recurso o según la especificación R4 si no hay ningún perfil presente. Este es el nivel de validación predeterminado para AWS HealthLake.
+ `structure-only`: Los recursos se validan con el R4 e ignoran los perfiles a los que se hace referencia.
+ `minimal`: Los recursos se validan mínimamente, ignorando ciertas reglas de R4. Los recursos que no superen las comprobaciones de estructura requeridas se search/analytics actualizarán para incluir una advertencia para la auditoría.
Los recursos actualizados con el nivel de validación mínimo pueden incorporarse a un almacén de datos a pesar de no pasar la validación necesaria para la indexación de las búsquedas. En este caso, los recursos se actualizarán para incluir una extensión específica de Healthlake para documentar dichos errores:
```
{
"url": "http://healthlake.amazonaws.com/fhir/StructureDefinition/validation-issue",
"valueString": "{\"resourceType\":\"OperationOutcome\",\"issue\":[{\"severity\":\"error\",\"code\":\"processing\",\"details\":{\"text\":\"FHIR resource in payload failed FHIR validation rules.\"},\"diagnostics\":\"FHIR resource in payload failed FHIR validation rules.\"}]}"
}
```
Además, se incluirá el siguiente encabezado de respuesta HTTP con el valor «true»:
```
x-amzn-healthlake-validation-issues : true
```
**nota**
Tenga en cuenta que es posible que los datos ingresados que tengan un formato incorrecto según la especificación R4 no se puedan buscar como se esperaba si se presentan estos errores.
# Modificación de recursos con la operación PATCH
AWS HealthLake admite la operación PATCH para los recursos del FHIR, lo que le permite modificar los recursos seleccionando elementos específicos para añadirlos, sustituirlos o eliminarlos sin necesidad de actualizar todo el recurso. Esta operación resulta especialmente útil cuando se necesita:
+ Realice actualizaciones específicas en recursos de gran tamaño
+ Reduzca el uso del ancho de banda de
+ Realice modificaciones atómicas en elementos de recursos específicos
+ Minimice el riesgo de sobrescribir los cambios simultáneos
+ Actualice los recursos como parte de los flujos de trabajo por lotes y transacciones
## Formatos PATCH compatibles
AWS HealthLake admite dos formatos PATCH estándar:
### Parche JSON (RFC 6902)
Utiliza la sintaxis JSON Pointer para seleccionar los elementos según su posición en la estructura de recursos.
**Tipo de contenido:** `application/json-patch+json`
### FHIRPath Parche (especificación FHIR R4)
Utiliza FHIRPath expresiones para seleccionar los elementos según su contenido y sus relaciones, lo que proporciona un enfoque de aplicación de parches nativo del FHIR.
**Tipo de contenido:** `application/fhir+json`
## De uso
### Operaciones directas de PATCH
La operación PATCH se puede invocar directamente en los recursos del FHIR mediante el método HTTP PATCH:
```
PATCH [base]/[resource-type]/[id]{?_format=[mime-type]}
```
### PATCH en paquetes
Las operaciones PATCH se pueden incluir como entradas en los paquetes del FHIR `batch` o bien`transaction`, lo que permite combinar las operaciones de parche con otras interacciones del FHIR (crear, leer, actualizar, eliminar) en una sola solicitud.
+ **Paquetes de transacciones**: todas las entradas se realizan correctamente o fallan de forma atómica
+ **Paquetes de lotes**: cada entrada se procesa de forma independiente
## Formato de parche JSON
### Operaciones admitidas
| Operación | Description (Descripción) |
| --- | --- |
| add | Agregue un nuevo valor al recurso |
| remove | Eliminar un valor del recurso |
| replace | Reemplace un valor existente en el recurso |
| move | Elimine un valor de una ubicación y agréguelo a otra |
| copy | Copie un valor de una ubicación a otra |
| test | Compruebe que un valor en la ubicación de destino es igual a un valor especificado |
### Sintaxis de ruta
El parche JSON utiliza la sintaxis JSON Pointer (RFC 6901):
| Ejemplo de ruta | Description (Descripción) |
| --- | --- |
| /name/0/family | Elemento familiar del nombre |
| /telecom/- | Añadir a la matriz de telecomunicaciones |
| /active | Elemento activo a nivel de raíz |
| /address/0/line/1 | Segunda línea de la primera dirección |
### Ejemplos
**Solicitud directa de parches JSON con múltiples operaciones**
```
PATCH [base]/Patient/example
Content-Type: application/json-patch+json
If-Match: W/"1"
[
{
"op": "replace",
"path": "/name/0/family",
"value": "Smith"
},
{
"op": "add",
"path": "/telecom/-",
"value": {
"system": "phone",
"value": "555-555-5555",
"use": "home"
}
},
{
"op": "remove",
"path": "/address/0"
},
{
"op": "move",
"from": "/name/0/family",
"path": "/name/1/family"
},
{
"op": "test",
"path": "/gender",
"value": "male"
},
{
"op": "copy",
"from": "/name/0",
"path": "/name/1"
}
]
```
**Solicitud directa de parches JSON con una sola operación**
```
PATCH [base]/Patient/example
Content-Type: application/json-patch+json
[
{
"op": "replace",
"path": "/active",
"value": false
}
]
```
**Parche JSON en paquete**
Utilice un recurso binario que contenga la carga útil del parche JSON codificada en base64:
```
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [{
"resource": {
"resourceType": "Binary",
"contentType": "application/json-patch+json",
"data": "W3sib3AiOiJhZGQiLCJwYXRoIjoiL2JpcnRoRGF0ZSIsInZhbHVlIjoiMTk5MC0wMS0wMSJ9XQ=="
},
"request": {
"method": "PATCH",
"url": "Patient/123"
}
}]
}
```
## FHIRPath Formato de parche
### Operaciones admitidas
| Operación | Description (Descripción) |
| --- | --- |
| add | Añadir un elemento nuevo a un recurso |
| insert | Inserte un elemento en una posición específica de una lista |
| delete | Eliminar un elemento de un recurso |
| replace | Reemplace el valor de un elemento existente |
| move | Reordenar los elementos de una lista |
### Sintaxis de ruta
FHIRPath El parche usa FHIRPath expresiones que admiten:
+ Acceso **basado en índices**: `Patient.name[0]`
+ **Filtrar** con: `where()` `Patient.name.where(use = 'official')`
+ **Lógica booleana**: `Patient.telecom.where(system = 'phone' and use = 'work')`
+ **Funciones de subconjuntos:,** `first()` `last()`
+ **Comprobaciones de existencia**:`exists()`, `count()`
+ **Navegación polimórfica**: `Observation.value`
### Ejemplos
**Solicitud de parche directa FHIRPath**
```
PATCH [base]/Patient/123
Content-Type: application/fhir+json
Authorization: ...
{
"resourceType": "Parameters",
"parameter": [{
"name": "operation",
"part": [
{ "name": "type", "valueCode": "add" },
{ "name": "path", "valueString": "Patient" },
{ "name": "name", "valueString": "birthDate" },
{ "name": "value", "valueDate": "1990-01-01" }
]
}]
}
```
**FHIRPath Parche en paquete**
Utilice un recurso de parámetros como recurso de entrada con`method: PATCH`:
```
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [{
"resource": {
"resourceType": "Parameters",
"parameter": [{
"name": "operation",
"part": [
{ "name": "type", "valueCode": "add" },
{ "name": "path", "valueString": "Patient" },
{ "name": "name", "valueString": "birthDate" },
{ "name": "value", "valueDate": "1990-01-01" }
]
}]
},
"request": {
"method": "PATCH",
"url": "Patient/123"
}
}]
}
```
## Encabezados de solicitud
| Encabezado | Obligatorio | Descripción |
| --- | --- | --- |
| Content-Type | Sí | application/json-patch\$1jsonpara JSON Patch o application/fhir\$1json para FHIRPath Patch |
| If-Match | No | Actualización condicional específica de la versión mediante ETag |
## Respuesta de ejemplo
La operación devuelve el recurso actualizado con la información de la nueva versión:
```
HTTP/1.1 200 OK
Content-Type: application/fhir+json
ETag: W/"2"
Last-Modified: Mon, 05 May 2025 10:10:10 GMT
{
"resourceType": "Patient",
"id": "example",
"active": true,
"name": [
{
"family": "Smith",
"given": ["John"]
}
],
"telecom": [
{
"system": "phone",
"value": "555-555-5555",
"use": "home"
}
],
"meta": {
"versionId": "2",
"lastUpdated": "2025-05-05T10:10:10Z"
}
}
```
## Comportamiento
La operación PATCH:
+ Valida la sintaxis del parche según la especificación correspondiente (RFC 6902 para JSON Patch, FHIR R4 para Patch) FHIRPath
+ Aplica las operaciones de forma atómica: todas las operaciones se realizan correctamente o todas fallan
+ Actualiza el ID de versión del recurso y crea una nueva entrada en el historial
+ Conserva el recurso original en el historial antes de aplicar los cambios
+ Valida las restricciones de recursos del FHIR después de aplicar los parches
+ Admite actualizaciones condicionales mediante el encabezado If-Match con ETag
## Gestión de errores
La operación gestiona las siguientes condiciones de error:
+ **400 Solicitud errónea**: sintaxis de parche no válida (solicitud no conforme o documento de parche mal formado)
+ **404 No encontrado: no se encontró** el recurso (el ID especificado no existe)
+ **409 Conflicto**: conflicto de versiones (se proporciona un identificador de versión no actualizado o actualizaciones simultáneas)
+ **422 Entidad inprocesable**: las operaciones de parche no se pueden aplicar a los elementos de recursos especificados
## Resumen de capacidades
| Funcionalidad | Parche JSON | FHIRPath Parche |
| --- | --- | --- |
| Tipo de contenido | application/json-patch\$1json | application/fhir\$1json |
| Formato de ruta | Puntero JSON (RFC 6901) | FHIRPath expresiones |
| API DIRECT PATCH | Soportado | compatible |
| Batch de paquetes | Compatible (mediante binario) | Compatible (mediante parámetros) |
| Transacción de paquete | Compatible (mediante binario) | Compatible (mediante parámetros) |
| Operaciones | añadir, eliminar, reemplazar, mover, copiar, probar | añadir, insertar, eliminar, reemplazar, mover |
## Limitaciones
+ No se admiten las operaciones PATCH condicionales que utilizan condiciones de búsqueda
+ Los paquetes de parches JSON deben utilizar recursos binarios con contenido codificado en base64
+ FHIRPath Los parches incluidos en los paquetes deben usar recursos de parámetros
## Recursos adicionales
Para obtener más información sobre las operaciones PATCH, consulte:
+ [Documentación del PARCHE FHIR R4](https://hl7.org/fhir/http.html#patch)
+ [Especificación del parche FHIR R4 FHIRPath ](https://hl7.org/fhir/fhirpatch.html)
+ [RFC 6902: parche JSON](https://datatracker.ietf.org/doc/html/rfc6902#section-4)
+ [RFC 6901: puntero JSON](https://datatracker.ietf.org/doc/html/rfc6901)
# Agrupación de recursos del FHIR
Un FHIR `Bundle` es un contenedor que contiene una colección de recursos del FHIR. AWS HealthLake AWS HealthLake admite dos tipos de paquetes con diferentes comportamientos de procesamiento.
[https://hl7.org/fhir/R4/http.html#transaction](https://hl7.org/fhir/R4/http.html#transaction)los paquetes procesan cada recurso de forma independiente. Si un recurso falla, los recursos restantes aún pueden funcionar correctamente. Cada operación se procesa de forma individual y el procesamiento continúa incluso cuando algunas operaciones fallan. Utilice paquetes por lotes para operaciones masivas en las que sea aceptable un éxito parcial, como cargar varios historiales de pacientes no relacionados.
[https://hl7.org/fhir/R4/http.html#transaction](https://hl7.org/fhir/R4/http.html#transaction)los paquetes procesan todos los recursos de forma atómica como una sola unidad. Todas las operaciones de recursos se realizan correctamente o no AWS HealthLake se compromete ninguna de ellas. Utilice los paquetes de transacciones cuando necesite garantizar la integridad referencial en todos los recursos relacionados, por ejemplo, si crea un paciente con observaciones y afecciones relacionadas, en el que todos los datos deben registrarse juntos.
**Diferencias entre lotes y paquetes de transacciones**
| Característica | Lote | Transacción |
| --- | --- | --- |
| Modelo de procesamiento | Cada operación se realiza correctamente o fracasa de forma independiente. | Todas las operaciones tienen éxito o fallan como una sola unidad atómica. |
| Administración de errores | El procesamiento continúa incluso si las operaciones individuales fallan. | Se produce un error en todo el paquete si se produce un error en una sola operación. |
| Orden de ejecución | La orden de ejecución no está garantizada. | Las operaciones se procesan en el orden especificado. |
| Integridad referencial | No se aplica en todas las operaciones. | Se aplica a los recursos referenciados localmente dentro del paquete. |
| Más adecuado para | Operaciones masivas en las que es aceptable un éxito parcial. | Recursos relacionados que deben crearse o actualizarse juntos. |
Puede agrupar recursos del FHIR del mismo tipo o de tipos diferentes, y estos pueden incluir una combinación de operaciones del FHIR`create`, como, `read` `update``delete`, y. `patch` Para obtener información adicional, consulte el [paquete de recursos](https://hl7.org/fhir/R4/Bundle) en la documentación del **FHIR R4**.
A continuación se muestran ejemplos de casos de uso para cada tipo de paquete.
Paquetes por lotes
+ Cargue varios registros de pacientes no relacionados de diferentes centros durante la sincronización de datos nocturna.
+ Cargue de forma masiva los registros históricos de medicamentos cuando algunos registros puedan tener problemas de validación.
+ Carga datos de referencia, como organizaciones y profesionales, de forma que los errores individuales no afecten a otras entradas.
Paquetes de transacciones
+ Cree un paciente con las observaciones y afecciones relacionadas durante un ingreso al servicio de urgencias, donde todos los datos deben registrarse juntos.
+ Actualice la lista de medicamentos del paciente y la información relacionada con las alergias, que debe ser coherente.
+ Registre un encuentro completo con el paciente, las observaciones, los procedimientos y la información de facturación como una sola unidad atómica.
**importante**
Tanto los paquetes de lotes como los de transacciones utilizan la misma estructura `Bundle` de recursos. La única diferencia es el valor del `type` campo.
El siguiente ejemplo muestra un paquete de transacciones con varios tipos de recursos y operaciones.
```
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [
{
"fullUrl": "urn:uuid:4f6a30fb-cd3c-4ab6-8757-532101f72065",
"resource": {
"resourceType": "Patient",
"id": "new-patient",
"active": true,
"name": [
{
"family": "Johnson",
"given": [
"Sarah"
]
}
],
"gender": "female",
"birthDate": "1985-08-12",
"telecom": [
{
"system": "phone",
"value": "555-123-4567",
"use": "home"
}
]
},
"request": {
"method": "POST",
"url": "Patient"
}
},
{
"fullUrl": "urn:uuid:7f83f473-d8cc-4a8d-86d3-9d9876a3248b",
"resource": {
"resourceType": "Observation",
"id": "blood-pressure",
"status": "final",
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "85354-9",
"display": "Blood pressure panel"
}
],
"text": "Blood pressure panel"
},
"subject": {
"reference": "urn:uuid:4f6a30fb-cd3c-4ab6-8757-532101f72065"
},
"effectiveDateTime": "2023-10-15T09:30:00Z",
"component": [
{
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "8480-6",
"display": "Systolic blood pressure"
}
]
},
"valueQuantity": {
"value": 120,
"unit": "mmHg",
"system": "http://unitsofmeasure.org",
"code": "mm[Hg]"
}
},
{
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "8462-4",
"display": "Diastolic blood pressure"
}
]
},
"valueQuantity": {
"value": 80,
"unit": "mmHg",
"system": "http://unitsofmeasure.org",
"code": "mm[Hg]"
}
}
]
},
"request": {
"method": "POST",
"url": "Observation"
}
},
{
"resource": {
"resourceType": "Appointment",
"id": "appointment-123",
"status": "booked",
"description": "Annual physical examination",
"start": "2023-11-15T09:00:00Z",
"end": "2023-11-15T09:30:00Z",
"participant": [
{
"actor": {
"reference": "urn:uuid:4f6a30fb-cd3c-4ab6-8757-532101f72065"
},
"status": "accepted"
}
]
},
"request": {
"method": "PUT",
"url": "Appointment/appointment-123"
}
},
{
"request": {
"method": "DELETE",
"url": "MedicationRequest/med-request-456"
}
}
]
}
```
## Agrupar los recursos del FHIR como entidades independientes
**Para agrupar los recursos del FHIR como entidades independientes**
1. Recolecta HealthLake `region` y `datastoreId` valora. 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`. *No* especifique un tipo de recurso FHIR en la URL. Para ver la ruta URL completa en el siguiente ejemplo, desplázate sobre el botón **Copiar**.
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
```
1. Crea un cuerpo JSON para la solicitud y especifica cada verbo HTTP como parte de los `method` elementos. En el siguiente ejemplo, se utiliza una interacción de `batch` tipos con el `Bundle` recurso para crear `Medication` recursos `Patient` y nuevos. Todas las secciones obligatorias se comentan en consecuencia. Para realizar este procedimiento, guarde el archivo como`batch-independent.json`.
```
{
"resourceType": "Bundle",
"id": "bundle-batch",
"meta": {
"lastUpdated": "2014-08-18T01:43:30Z"
},
"type": "batch",
"entry": [
{
"resource": {
"resourceType": "Patient",
"meta": {
"lastUpdated": "2022-06-03T17:53:36.724Z"
},
"text": {
"status": "generated",
"div": "Some narrative"
},
"active": true,
"name": [
{
"use": "official",
"family": "Jackson",
"given": [
"Mateo",
"James"
]
}
],
"gender": "male",
"birthDate": "1974-12-25"
},
"request": {
"method": "POST",
"url": "Patient"
}
},
{
"resource": {
"resourceType": "Medication",
"id": "med0310",
"contained": [
{
"resourceType": "Substance",
"id": "sub03",
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "55452001",
"display": "Oxycodone (substance)"
}
]
}
}
],
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "430127000",
"display": "Oral Form Oxycodone (product)"
}
]
},
"form": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "385055001",
"display": "Tablet dose form (qualifier value)"
}
]
},
"ingredient": [
{
"itemReference": {
"reference": "#sub03"
},
"strength": {
"numerator": {
"value": 5,
"system": "http://unitsofmeasure.org",
"code": "mg"
},
"denominator": {
"value": 1,
"system": "http://terminology.hl7.org/CodeSystem/v3-orderableDrugForm",
"code": "TAB"
}
}
}
]
},
"request": {
"method": "POST",
"url": "Medication"
}
}
]
}
```
1. Envíe la solicitud . El tipo de `Bundle` lote del FHIR utiliza una `POST` solicitud con la [versión 4 de AWS Signature](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) o SMART previa autorización del FHIR. El siguiente ejemplo de código utiliza la herramienta de línea de `curl` comandos con fines de demostración.
------
#### [ SigV4 ]
autorización SigV4
```
curl --request POST \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/' \
--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' \
--data @batch-type.json
```
------
#### [ SMART on FHIR ]
Ejemplo de autorización SMART on FHIR para el 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
La persona que llama puede asignar permisos en la lambda de autorización. Para obtener más información, consulte [OAuth osciloscopios 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
El servidor devuelve una respuesta que muestra los `Medication` recursos `Patient` y los recursos creados como resultado de la solicitud `Bundle` por lotes.
## Condicional PUTs en paquetes
AWS HealthLake admite las actualizaciones condicionales dentro de los paquetes mediante los siguientes parámetros de consulta:
+ `_id`(independiente)
+ `_id`en combinación con uno de los siguientes:
+ `_tag`
+ `_createdAt`
+ `_lastUpdated`
Cuando utilizas la opción condicional PUTs en paquetes, AWS HealthLake evalúa los parámetros de la consulta comparándolos con los recursos existentes y toma medidas en función de los resultados de las coincidencias.
**Comportamiento de actualización condicional**
| Escenario | Estado HTTP | Acción emprendida |
| --- | --- | --- |
| Recurso sin ID proporcionado | 201 Creado | Siempre crea un recurso nuevo. |
| Recurso con un nuevo identificador (no coincide) | 201 Creado | Crea un nuevo recurso con el ID especificado. |
| Recurso con un ID existente (coincidencia única) | 200 OK | Actualiza el recurso coincidente. |
| Recurso con un identificador existente (se detectó un conflicto) | Conflicto, 409 | Devuelve un error. No se realiza ningún cambio. |
| Recurso con un identificador existente (los identificadores no coinciden) | 400: solicitud maligna | Devuelve un error. No se realiza ningún cambio. |
| Varios recursos cumplen las condiciones | Condición previa con error, 412 | Devuelve un error. No se realiza ningún cambio. |
En el siguiente paquete de ejemplo con una actualización condicional, el `Patient` recurso con el identificador FHIR se `476` actualiza solo si `_lastUpdated=lt2025-04-20` se cumple la condición.
```
{
"resourceType": "Bundle",
"id": "bundle-batch",
"meta": {
"lastUpdated": "2014-08-18T01:43:30Z"
},
"type": "batch",
"entry": [
{
"resource": {
"resourceType": "Patient",
"id": "476",
"meta": {
"lastUpdated": "2022-06-03T17:53:36.724Z"
},
"active": true,
"name": [
{
"use": "official",
"family": "Jackson",
"given": [
"Mateo",
"James"
]
}
],
"gender": "male",
"birthDate": "1974-12-25"
},
"request": {
"method": "PUT",
"url": "Patient?_id=476&_lastUpdated=lt2025-04-20"
}
},
{
"resource": {
"resourceType": "Medication",
"id": "med0310",
"contained": [
{
"resourceType": "Substance",
"id": "sub03",
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "55452001",
"display": "Oxycodone (substance)"
}
]
}
}
],
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "430127000",
"display": "Oral Form Oxycodone (product)"
}
]
},
"form": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "385055001",
"display": "Tablet dose form (qualifier value)"
}
]
},
"ingredient": [
{
"itemReference": {
"reference": "#sub03"
},
"strength": {
"numerator": {
"value": 5,
"system": "http://unitsofmeasure.org",
"code": "mg"
},
"denominator": {
"value": 1,
"system": "http://terminology.hl7.org/CodeSystem/v3-orderableDrugForm",
"code": "TAB"
}
}
}
]
},
"request": {
"method": "POST",
"url": "Medication"
}
}
]
}
```
## Agrupar los recursos del FHIR como una sola entidad
**Para agrupar los recursos del FHIR como una sola entidad**
1. HealthLake `region`Recopila y `datastoreId` valora. 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`. Incluya el tipo de recurso FHIR `Bundle` como parte de la URL. Para ver la ruta URL completa en el siguiente ejemplo, desplázate sobre el botón **Copiar**.
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Bundle
```
1. Crea un cuerpo JSON para la solicitud, especificando los recursos del FHIR que quieres agrupar. En el siguiente ejemplo, se agrupan dos `Patient` recursos. HealthLake Para realizar este procedimiento, guarde el archivo como`batch-single.json`.
```
{
"resourceType": "Bundle",
"id": "bundle-minimal",
"language": "en-US",
"identifier": {
"system": "urn:oid:1.2.3.4.5",
"value": "28b95815-76ce-457b-b7ae-a972e527db4f"
},
"type": "document",
"timestamp": "2020-12-11T14:30:00+01:00",
"entry": [
{
"fullUrl": "urn:uuid:f40b07e3-37e8-48c3-bf1c-ae70fe12dabf",
"resource": {
"resourceType": "Composition",
"id": "f40b07e3-37e8-48c3-bf1c-ae70fe12dabf",
"status": "final",
"type": {
"coding": [
{
"system": "http://loinc.org",
"code": "60591-5",
"display": "Patient summary Document"
}
]
},
"date": "2020-12-11T14:30:00+01:00",
"author": [
{
"reference": "urn:uuid:45271f7f-63ab-4946-970f-3daaaa0663ff"
}
],
"title": "Patient Summary as of December 7, 2020 14:30"
}
},
{
"fullUrl": "urn:uuid:45271f7f-63ab-4946-970f-3daaaa0663ff",
"resource": {
"resourceType": "Practitioner",
"id": "45271f7f-63ab-4946-970f-3daaaa0663ff",
"active": true,
"name": [
{
"family": "Doe",
"given": [
"John"
]
}
]
}
}
]
}
```
1. Envíe la solicitud . El tipo de `Bundle` documento FHIR utiliza una `POST` solicitud con el protocolo de [AWS firma Signature versión 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html). El siguiente ejemplo de código utiliza la herramienta de línea de `curl` comandos con fines de demostración.
------
#### [ SigV4 ]
autorización SigV4
```
curl --request POST \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Bundle' \
--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' \
--data @document-type.json
```
------
#### [ SMART on FHIR ]
Ejemplo de autorización SMART on FHIR para el 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
La persona que llama puede asignar permisos en la lambda de autorización. Para obtener más información, consulte [OAuth osciloscopios 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
El servidor devuelve una respuesta que muestra dos `Patient` recursos creados como resultado de la solicitud de tipo de `Bundle` documento.
## Configurar el nivel de validación de los paquetes
Al agrupar los recursos del FHIR, puede especificar opcionalmente un encabezado `x-amzn-healthlake-fhir-validation-level` HTTP para configurar un nivel de validación para el recurso. Este nivel de validación se establecerá para todas las solicitudes de creación y actualización del paquete. AWS HealthLake actualmente admite los siguientes niveles de validación:
+ `strict`: Los recursos se validan según el elemento de perfil del recurso o según la especificación R4 si no hay ningún perfil presente. Este es el nivel de validación predeterminado para AWS HealthLake.
+ `structure-only`: Los recursos se validan con el R4 e ignoran los perfiles a los que se hace referencia.
+ `minimal`: Los recursos se validan mínimamente, ignorando ciertas reglas de R4. Los recursos que no superen las comprobaciones de estructura requeridas se search/analytics actualizarán para incluir una advertencia para la auditoría.
Los recursos incluidos con un nivel de validación mínimo pueden incorporarse a un almacén de datos a pesar de no pasar la validación necesaria para la indexación de las búsquedas. En este caso, los recursos se actualizarán para incluir una extensión específica de Healthlake para documentar dichos errores, y las entradas de la respuesta del paquete incluirán los siguientes recursos: OperationOutcome
```
{
"resourceType": "Bundle",
"type": "batch-response",
"timestamp": "2025-08-25T22:58:48.846287342Z",
"entry": [
{
"response": {
"status": "201",
"location": "Patient/195abc49-ba8e-4c8b-95c2-abc88fef7544/_history/1",
"etag": "W/\"1\"",
"lastModified": "2025-08-25T22:58:48.801245445Z",
"outcome": {
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "processing",
"details": {
"text": "FHIR resource in payload failed FHIR validation rules."
},
"diagnostics": "FHIR resource in payload failed FHIR validation rules."
}
]
}
}
}
]
}
```
Además, se incluirá el siguiente encabezado de respuesta HTTP con el valor «true»:
```
x-amzn-healthlake-validation-issues : true
```
**nota**
Tenga en cuenta que es posible que los datos ingresados que tengan un formato incorrecto según la especificación R4 no se puedan buscar como se esperaba si se presentan estos errores.
## Soporte limitado para el tipo de paquete «mensaje»
HealthLake proporciona un soporte limitado para el tipo de paquete FHIR `message` mediante un proceso de conversión interno. Este soporte está diseñado para situaciones en las que los paquetes de mensajes no se pueden volver a formatear en su origen, por ejemplo, cuando se ingieren ficheros ADT (admisión, alta, transferencia) de sistemas hospitalarios antiguos.
**aviso**
Esta función requiere la inclusión explícita de las AWS cuentas en la lista y no impone la semántica de los mensajes R4 ni la integridad referencial del FHIR. Póngase en contacto con AWS Support para solicitar la activación de su cuenta antes de usar paquetes de mensajes.
### Diferencias clave con respecto al procesamiento de mensajes estándar
+ **Paquetes de mensajes** (especificación FHIR): la primera entrada debe ser una `MessageHeader` que haga referencia a otros recursos. Los recursos carecen de `request` objetos individuales y el MessageHeader evento determina las acciones de procesamiento.
+ **HealthLake Procesamiento**: convierte los paquetes de mensajes en paquetes por lotes mediante la asignación automática de operaciones PUT a cada entrada de recursos. Los recursos se procesan de forma independiente sin imponer la semántica de los mensajes ni la integridad referencial.
### Limitaciones importantes
+ No se aplican las reglas de procesamiento específicas de los mensajes del FHIR R4
+ No hay integridad transaccional en todos los recursos
+ Las referencias entre recursos no están validadas
+ Requiere la inclusión explícita de cuentas en la lista
### Ejemplo de estructura de paquete de mensajes
```
{
"resourceType": "Bundle",
"type": "message",
"entry": [
{
"resource": {
"resourceType": "MessageHeader",
"eventCoding": {
"system": "http://hl7.org/fhir/us/davinci-alerts/CodeSystem/notification-event",
"code": "notification-admit"
},
"focus": [{"reference": "Encounter/example-id"}]
}
},
{
"resource": {"resourceType": "Patient", "id": "example-id"}
},
{
"resource": {"resourceType": "Encounter", "id": "example-id"}
}
]
}
```
**nota**
Cada recurso se almacena de forma independiente, como si se hubiera enviado mediante operaciones PUT individuales. Si se requiere una validación completa de la semántica de los mensajes o de la integridad referencial del FHIR, procese previamente los paquetes de mensajes o implemente una validación a nivel de aplicación antes de enviarlos.
## Transacciones de paquetes asíncronas
AWS HealthLake admite el `Bundle` tipo asíncrono `transaction` que le permite enviar transacciones con hasta 500 recursos. Al enviar una transacción asíncrona, la pone en HealthLake cola para su procesamiento e inmediatamente devuelve una URL de sondeo. Puedes usar esta URL para comprobar el estado y recuperar la respuesta. Sigue el patrón de paquetes [asíncronos del FHIR](https://hl7.org/fhir/async-bundle.html).
**Cuándo usar transacciones asíncronas**
+ Debe enviar más de 100 recursos (límite sincrónico) en una sola transacción.
+ Desea evitar bloquear su solicitud mientras espera a que se complete el procesamiento de la transacción.
+ Necesita procesar grandes volúmenes de recursos relacionados con un mejor rendimiento.
**importante**
Los resultados de la encuesta están disponibles durante 90 días después de que se complete la transacción. Después de este período de 90 días, la URL de la encuesta ya no devuelve los resultados. Diseñe su integración para recuperar y almacenar los resultados en esta ventana.
**nota**
El `Bundle` tipo síncrono `transaction` sigue admitiendo hasta 100 recursos y es el modo de procesamiento predeterminado. Si envía un `Bundle` tipo `transaction` con más de 100 recursos sin el `Prefer: respond-async` encabezado, HealthLake devuelve un `422 Unprocessable Entity` error. Los paquetes con tipo no `batch` se admiten para el procesamiento asíncrono; solo los `Bundle` tipos se `transaction` pueden enviar de forma asíncrona (con un máximo de 500 operaciones).
### Enviar una transacción asíncrona
Para enviar una transacción asíncrona, envíe una `POST` solicitud al punto final del almacén de datos con el encabezado. `Prefer: respond-async` El paquete debe tener un tipo. `transaction` Los paquetes con un tipo no `batch` se admiten para el procesamiento asíncrono de paquetes.
HealthLake realiza las validaciones iniciales del paquete en el momento de su envío. Si la validación se realiza correctamente, HealthLake devuelve HTTP 202 Accepted con un encabezado de `content-location` respuesta que contiene la URL de la encuesta.
**Para enviar un tipo `Bundle` asíncrono `transaction`**
1. Envíe una `POST` solicitud al punto final del almacén de HealthLake datos.
```
POST https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/
```
1. Cree un cuerpo JSON para la solicitud con el tipo de paquete`transaction`. Para este procedimiento, guarde el archivo como`async-transaction.json`.
```
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [
{
"resource": {
"resourceType": "Patient",
"active": true,
"name": [
{
"use": "official",
"family": "Smith",
"given": ["Jane"]
}
],
"gender": "female",
"birthDate": "1990-01-15"
},
"request": {
"method": "POST",
"url": "Patient"
}
},
{
"resource": {
"resourceType": "Observation",
"status": "final",
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "85354-9",
"display": "Blood pressure panel"
}
]
},
"subject": {
"reference": "urn:uuid:example-patient-id"
}
},
"request": {
"method": "POST",
"url": "Observation"
}
}
]
}
```
1. Envíe la solicitud con el `Prefer: respond-async` encabezado. El tipo de `Bundle` transacción del FHIR utiliza una `POST` solicitud con la [versión 4 de la AWS firma](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) o SMART con la autorización del FHIR. El siguiente ejemplo de código utiliza la herramienta de línea de `curl` comandos con fines de demostración.
------
#### [ SigV4 ]
autorización SigV4
```
curl --request POST \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/' \
--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' \
--header 'Prefer: respond-async' \
--data @async-transaction.json
```
------
#### [ SMART on FHIR ]
Ejemplo de autorización SMART on FHIR para el 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.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
La persona que llama puede asignar permisos en la lambda de autorización. Para obtener más información, consulte [OAuth osciloscopios 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
1. Si el envío se realiza correctamente, el servidor devuelve HTTP 202 Accepted. El encabezado de la `content-location` respuesta contiene la URL de la encuesta. El cuerpo de la respuesta es un `OperationOutcome` recurso.
```
HTTP/1.1 202 Accepted
content-location: https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Transaction/transactionId
```
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "Submitted Asynchronous Bundle Transaction",
"location": [
"https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Transaction/transactionId"
]
}
]
}
```
### Sondeo del estado de la transacción
Después de enviar una transacción asíncrona, usa la URL de sondeo del encabezado de `content-location` respuesta para comprobar el estado de la transacción. Envía una `GET` solicitud a la URL de la encuesta.
**nota**
En el caso de los almacenes de datos habilitados para SMART o FHIR, el token de autorización debe incluir `read` permisos sobre el tipo de `Transaction` recurso para comprobar el estado de la transacción. Para obtener más información sobre SMART en los ámbitos del FHIR, consulte. [Los osciloscopios SMART on FHIR OAuth 2.0 son compatibles con HealthLake](reference-smart-on-fhir-oauth-scopes.md)
Envíe una `GET` solicitud a la URL de la encuesta. En el siguiente ejemplo, se utiliza la herramienta de línea de `curl` comandos.
------
#### [ SigV4 ]
Autorización SigV4
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Transaction/transactionId' \
--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'
```
------
#### [ SMART on FHIR ]
Autorización SMART sobre la FHIR. El token de autorización debe incluir `read` los permisos correspondientes al tipo `Transaction` de recurso.
```
curl --request GET \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Transaction/transactionId' \
--header 'Authorization: Bearer $SMART_ACCESS_TOKEN' \
--header 'Accept: application/json'
```
------
En la siguiente tabla se describen las posibles respuestas.
**Códigos de respuesta al sondeo**
| Estado HTTP | Significado | Cuerpo de respuesta |
| --- | --- | --- |
| 202: aceptada | La transacción está en cola | OperationOutcomecon el diagnóstico «ENVIADO» |
| 202: aceptada | La transacción se está procesando | OperationOutcomecon el diagnóstico «IN\$1PROGRESS» |
| 200 OK | La transacción se completó correctamente | Bundlecon tipo transaction-response |
| 4xx/5xx | Transacción fallida | OperationOutcomecon detalles del error |
Los siguientes ejemplos muestran cada tipo de respuesta.
**Transacción en cola (202)**
```
{
"resourceType": "OperationOutcome",
"id": "transactionId",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "SUBMITTED"
}
]
}
```
**Procesamiento de transacciones (202)**
```
{
"resourceType": "OperationOutcome",
"id": "transactionId",
"issue": [
{
"severity": "information",
"code": "informational",
"diagnostics": "IN_PROGRESS"
}
]
}
```
**Transacción completada (200)**
```
{
"resourceType": "Bundle",
"type": "transaction-response",
"entry": [
{
"response": {
"status": "201",
"location": "Patient/example-id/_history/1",
"etag": "W/\"1\"",
"lastModified": "2024-01-15T10:30:00.000Z"
}
},
{
"response": {
"status": "201",
"location": "Observation/example-id/_history/1",
"etag": "W/\"1\"",
"lastModified": "2024-01-15T10:30:00.000Z"
}
}
]
}
```
**Transacción fallida (4xx/5xx)**
```
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "exception",
"diagnostics": "Transaction failed: conflict detected on resource Patient/example-id"
}
]
}
```
### Procesando el pedido
Los paquetes de tipo asíncrono `transaction` están en cola, pero no se procesan siguiendo un orden de envío estricto. HealthLake optimiza el procesamiento en función de la capacidad disponible y la carga del sistema.
**importante**
No dependa de que las transacciones se procesen en el orden en que se enviaron. Por ejemplo, si envía la transacción A a las 10:00 a.m. y la transacción B a las 10:01 a.m., la transacción B podría completarse antes que la transacción A. Diseñe su solicitud para:
Gestione la out-of-order finalización.
Utilice la URL de la encuesta para realizar un seguimiento de cada transacción de forma independiente.
Implemente la secuenciación a nivel de aplicación si el orden es importante para su caso de uso.
### Cuotas y limitaciones
Las siguientes cuotas y límites de tasa se aplican a las transacciones asincrónicas.
**Cuotas de transacciones asincrónicas**
| Cuota | Valor | Ajustable |
| --- | --- | --- |
| Máximo de operaciones por transacción asíncrona | 500 | No |
| Máximo de transacciones pendientes por almacén de datos | 500 | Sí |
+ Las transacciones asincrónicas comparten los mismos límites de velocidad de la API definidos en. [Cuotas de servicio](reference-healthlake-endpoints-quotas.md#reference-healthlake-quotas)
+ El sondeo del estado de las transacciones comparte los mismos límites de velocidad de la API que las operaciones de lectura (`GET`) en los recursos del FHIR.
+ Si se alcanza el límite de transacciones pendientes, los envíos posteriores devuelven un error hasta que se completen las transacciones existentes.
### Gestión de errores
En el caso de un paquete de «transacciones», todos los recursos del FHIR contenidos en el paquete se procesan como una operación atómica. Todos los recursos de la operación deben realizarse correctamente o no se procesará ninguna operación del paquete.
Los errores se dividen en dos categorías: los errores de envío, que se HealthLake devuelven de forma sincrónica, y los errores de procesamiento, que se recuperan mediante un sondeo.
**Errores de envío**
HealthLake valida el paquete en el momento del envío y devuelve los errores de forma sincrónica antes de que la transacción se ponga en cola. Los errores de envío incluyen los errores de validación de recursos del FHIR no válidos, los tipos de recursos no admitidos, la superación del límite de 500 operaciones y el uso del `Prefer: respond-async` encabezado con paquetes de lotes. Si se ha alcanzado el límite de transacciones pendientes del almacén de datos, HealthLake devuelve un. `ThrottlingException` Cuando se produce un error de envío, la transacción no se pondrá en cola.
**Errores de procesamiento**
Los errores de procesamiento se producen después de poner la transacción en cola y se devuelven a través de la URL de sondeo. Estos incluyen los conflictos de transacciones, en los que otra operación modificó un recurso que forma parte de la transacción, y los errores del servidor durante el procesamiento. Cuando se produce un error de procesamiento, no se produce ninguna mutación de recursos para los recursos de la transacción. La URL del sondeo devolverá una `OperationOutcome` con los detalles del error.
# Eliminar un recurso del FHIR
La `delete` interacción del FHIR elimina un recurso del FHIR existente de un HealthLake almacén de datos. Para obtener información adicional, consulte la documentación de la [https://hl7.org/fhir/R4/http.html#delete](https://hl7.org/fhir/R4/http.html#delete)API ** RESTful R4 del FHIR**.
**Para eliminar un recurso del FHIR**
1. HealthLake `region`Recopila y `datastoreId` valora. Para obtener más información, consulte [Obtención de propiedades de los almacenes de datos](managing-data-stores-describe.md).
1. Determine el tipo de `Resource` FHIR que desea eliminar y recopile el `id` valor asociado. Para obtener más información, consulte [Tipos de recurso](reference-fhir-resource-types.md).
1. Cree una URL para la solicitud utilizando los valores recopilados para HealthLake `region` y`datastoreId`. Incluya también el `Resource` tipo FHIR y su correspondiente`id`. Para ver la ruta URL completa en el siguiente ejemplo, desplázate sobre el botón **Copiar**.
```
DELETE https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Resource/id
```
1. Envíe la solicitud . La `delete` interacción del FHIR utiliza una `DELETE` solicitud con la [versión 4 de la AWS firma](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) o SMART con la autorización del FHIR. En el siguiente `curl` ejemplo, se elimina un `Patient` recurso del FHIR existente de un HealthLake banco de datos. Para ver el ejemplo completo, desplácese sobre el botón **Copiar**.
------
#### [ SigV4 ]
Autorización SigV4
```
curl --request DELETE \
'https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient/id' \
--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 servidor devuelve un código de estado `204` HTTP que confirma que el recurso se ha eliminado del almacén de HealthLake datos. Si se produce un error en una solicitud de eliminación, recibirá una `400` serie de códigos de estado HTTP que indicará el motivo del error en la solicitud.
------
#### [ SMART on FHIR ]
Ejemplo de autorización SMART on FHIR para el tipo [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)de datos.
```
{
"AuthorizationStrategy": "SMART_ON_FHIR",
"FineGrainedAuthorizationEnabled": true,
"IdpLambdaArn": "arn:aws:lambda:your-region:your-account-id:function:your-lambda-name",
"Metadata": "{\"issuer\":\"https://ehr.example.com\", \"jwks_uri\":\"https://ehr.example.com/.well-known/jwks.json\",\"authorization_endpoint\":\"https://ehr.example.com/auth/authorize\",\"token_endpoint\":\"https://ehr.token.com/auth/token\",\"token_endpoint_auth_methods_supported\":[\"client_secret_basic\",\"foo\"],\"grant_types_supported\":[\"client_credential\",\"foo\"],\"registration_endpoint\":\"https://ehr.example.com/auth/register\",\"scopes_supported\":[\"openId\",\"profile\",\"launch\"],\"response_types_supported\":[\"code\"],\"management_endpoint\":\"https://ehr.example.com/user/manage\",\"introspection_endpoint\":\"https://ehr.example.com/user/introspect\",\"revocation_endpoint\":\"https://ehr.example.com/user/revoke\",\"code_challenge_methods_supported\":[\"S256\"],\"capabilities\":[\"launch-ehr\",\"sso-openid-connect\",\"client-public\",\"permission-v2\"]}"
}
```
La persona que llama puede asignar permisos en la lambda de autorización. Para obtener más información, consulte [OAuth osciloscopios 2.0](reference-smart-on-fhir-oauth-scopes.md).
------
#### [ AWS Console ]
1. Inicie sesión en la página [Ejecutar consultas](https://console.aws.amazon.com/healthlake/home#/crud) de la HealthLake consola.
2. En la sección de **configuración de consultas**, realice las siguientes selecciones.
+ **ID de almacén de datos**: elija un ID de almacén de datos para generar una cadena de consulta.
+ **Tipo de consulta**: elija`Delete`.
+ **Tipo de recurso**: elija el [tipo de recurso](reference-fhir-resource-types.md) FHIR que desee eliminar.
+ **ID de recurso**: introduzca el ID de recurso del FHIR.
3. Elija **Ejecutar consulta**.
------
## Eliminar los recursos del FHIR en función de las condiciones
La eliminación condicional resulta especialmente útil cuando no se conoce el identificador específico del recurso del FHIR, pero se dispone de otra información de identificación sobre el recurso que se desea eliminar.
La eliminación condicional le permite eliminar un recurso existente en función de los criterios de búsqueda y no de un ID de FHIR lógico. Cuando el servidor procesa la solicitud de eliminación, realiza una búsqueda utilizando las capacidades de búsqueda estándar para el tipo de recurso a fin de resolver un único identificador lógico para la solicitud.
### Cómo funciona la eliminación condicional
**La acción del servidor depende del número de coincidencias que encuentre:**
1. **No hay coincidencias**: el servidor intenta realizar una eliminación normal y responde adecuadamente (404 No se ha encontrado ningún recurso, 204 no se ha encontrado contenido para un recurso ya eliminado)
1. **Una coincidencia**: el servidor realiza una eliminación normal del recurso coincidente
1. **Coincidencias múltiples**: devuelve el error 412: no se pudo cumplir la condición previa, lo que indica que los criterios del cliente no eran lo suficientemente selectivos
### Escenarios de respuesta
AWS HealthLake gestiona las operaciones de borrado condicional con los siguientes patrones de respuesta:
**Operaciones exitosas**
+ Cuando los criterios de búsqueda identifican correctamente un único recurso activo, el sistema devuelve **204 Sin contenido** tras completar la eliminación, al igual que en las operaciones de eliminación estándar.
**Eliminación condicional basada en ID**
Al realizar una eliminación condicional basada en `id` parámetros adicionales (`createdAt`,`tag`, o`_lastUpdated`):
+ **204 Sin contenido**: el recurso ya se ha eliminado
+ **404 No encontrado**: el recurso no existe
+ **409 Conflicto**: el identificador coincide pero otros parámetros no coinciden
**Non-ID-Based Eliminación condicional**
Cuando no `id` se proporciona o cuando se utilizan parámetros distintos de `createdAt``tag`, o`_lastUpdated`:
+ **404 No se encontró**: no se encontraron coincidencias
**Situaciones de conflicto**
Varios escenarios dan como resultado 412 respuestas fallidas a una condición previa:
+ Varios recursos coinciden con sus criterios de búsqueda (los criterios no son lo suficientemente específicos)
+ La versión entra en conflicto cuando se utilizan ETag encabezados con `If-Match`
+ Las actualizaciones de recursos se producen entre las operaciones de búsqueda y eliminación
**Ejemplo de una eliminación condicional correcta**
En el siguiente ejemplo, se elimina un recurso para pacientes en función de criterios específicos:
```
DELETE https://healthlake.region.amazonaws.com/datastore/datastoreId/r4/Patient?name=peter&birthdate=2000-01-01&phone=1234567890
```
Esta solicitud elimina un recurso para pacientes en el que:
+ El nombre es «peter»
+ La fecha de nacimiento es el 1 de enero de 2000
+ El número de teléfono es 1234567890
**Prácticas recomendadas**
1. Utilice criterios de búsqueda específicos para evitar múltiples coincidencias y evitar errores 412.
1. Tenga en cuenta ETag los encabezados para el control de versiones cuando sea necesario para gestionar las modificaciones simultáneas.
1. Gestione las respuestas de error de forma adecuada:
+ Para 404: Refina tus criterios de búsqueda
+ Para 412: especifique los criterios o resuelva los conflictos de versiones
1. Prepárese para los conflictos de temporización en entornos de alta concurrencia, en los que los recursos pueden modificarse entre las operaciones de búsqueda y eliminación.
# Idempotencia y concurrencia
## Claves de idempotencia
AWS HealthLake admite claves de idempotencia para las `POST` operaciones del FHIR, lo que proporciona un mecanismo sólido para garantizar la integridad de los datos durante la creación de los recursos. Al incluir un UUID único como clave de idempotencia en el encabezado de la solicitud, las aplicaciones sanitarias pueden garantizar que cada recurso del FHIR se cree exactamente una vez, incluso en escenarios que impliquen inestabilidad de la red o reintentos automáticos.
Esta característica es particularmente crucial para los sistemas de salud, donde la duplicación de registros médicos podría tener graves consecuencias. Cuando se reciba una solicitud con la misma clave de idempotencia que una solicitud anterior, HealthLake devolverá el recurso original en lugar de crear un duplicado. Por ejemplo, esto podría ocurrir durante un ciclo de reintento o debido a canalizaciones de solicitudes redundantes. El uso de la clave de idempotencia permite mantener la coherencia de los datos y, HealthLake al mismo tiempo, proporciona una experiencia perfecta para las aplicaciones cliente que gestionan problemas de conectividad intermitentes.
### Implementación
```
POST //Patient
x-amz-fhir-idempotency-key: 123e4567-e89b-12d3-a456-426614174000
{
"resourceType": "Patient",
"name": [...]
}
```
### Escenarios de respuesta
Primera solicitud (201 creada)
+ El nuevo recurso se creó correctamente
+ La respuesta incluye el identificador del recurso
Solicitud duplicada (409 Conflicto)
+ Se detectó la misma clave de idempotencia
+ Recurso original devuelto
+ No se ha creado ningún recurso nuevo
Solicitud no válida (400 solicitudes incorrectas)
+ UUID mal formado
+ Faltan campos obligatorios
### Prácticas recomendadas
+ Genera un UUID único para cada nueva creación de recursos
+ Almacene las claves de idempotencia para la lógica de reintento
+ Utilice un formato de clave coherente: se recomienda el UUID v4
+ Implételo en las aplicaciones cliente que gestionen la creación de recursos
**nota**
Esta función es particularmente valiosa para los sistemas de salud que requieren una precisión de datos estricta y evitan la duplicación de registros médicos.
## ETag en AWS HealthLake
AWS HealthLake utiliza un control ETags de simultaneidad optimista en los recursos del FHIR, proporcionando un mecanismo fiable para gestionar las modificaciones simultáneas y mantener la coherencia de los datos. Un ETag es un identificador único que representa una versión específica de un recurso y funciona como un sistema de control de versiones a través de encabezados HTTP. Al leer o modificar los recursos, las aplicaciones pueden utilizarlos ETags para evitar sobrescrituras no deseadas y garantizar la integridad de los datos, especialmente en escenarios con posibles actualizaciones simultáneas.
### Ejemplo de implementación
```
// Initial Read
GET /fhir/Patient/123
Response:
ETag: W/"1"
// Update with If-Match
PUT /fhir/Patient/123
If-Match: W/"1"
{resource content}
// Create with If-None-Match
PUT /fhir/Patient/123
If-None-Match: *
{resource content}
// Succeeds only if resource doesn't exist
// Fails with 412 if resource exists
```
### Escenarios de respuesta
Funcionamiento exitoso (200 OK o 204 sin contenido)
+ ETag coincide con la versión actual
+ La operación se desarrolla según lo previsto
Conflicto de versión (error en la condición previa 412)
+ ETag no coincide con la versión actual
+ Actualización rechazada para evitar la pérdida de datos
### Prácticas recomendadas
+ Incluir ETags en todas las operaciones de actualización y eliminación
+ Implemente la lógica de reintento para gestionar los conflictos de versiones
+ Utilice If-None-Match: \$1 para escenarios create-if-not-exists
+ Compruebe siempre la ETag frescura antes de realizar modificaciones
Este sistema de control de simultaneidad es esencial para mantener la integridad de los datos de atención médica, especialmente en entornos con varios usuarios o sistemas que acceden a los mismos recursos y los modifican.