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. # 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 } ```