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.
# Los osciloscopios OAuth 2.0 SMART on FHIR son compatibles con HealthLake
HealthLake utiliza 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 FHIR V1, que incluye los `read` permisos (read/search) 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 de OAuth 2.0 que solicita que se devuelvan los datos del paciente en la respuesta de autorización. |
## Los alcances de los recursos 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.\* | La aplicación cliente para pacientes tiene read/write acceso 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 a todas las observaciones registradas read/write . |
| system/('read' \| 'write' \| \*) | system/\*.\* | 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/\*.\* | La aplicación cliente del sistema tiene acceso completo create/read update/delete //search a todos los datos de los recursos del FHIR. |
### SMART en los osciloscopios FHIR V2.2 es compatible con HealthLake
V2.2 amplía los ámbitos de la V2 con un filtrado basado en parámetros de búsqueda. Los servidores de autorización ahora pueden emitir alcances que restringen el acceso en función de características específicas de los datos y no solo por el tipo de recurso y la operación del CRUDS.
Todo lo relacionado con la versión 2 permanece inalterado. V2.2 es puramente aditivo:
+ Los osciloscopios V2 existentes (sin filtros) siguen funcionando como antes.
+ La gramática V2 se amplía con una cadena de `?param=value` consulta opcional.
+ Sin cambios en los niveles de alcance (`patient`/`user`/`system`), los tipos de recursos ni las letras CRUDS.
#### Requisitos previos
Antes de activar SMART en el FHIR V2.2, asegúrese de lo siguiente:
+ Su almacén de datos se creó con el valor `AuthorizationStrategy` establecido en `SMART_ON_FHIR` (es compatible con V1 y V2). Los almacenes de datos que utilizan `SMART_ON_FHIR_V1` o no `AWS_AUTH` son aptos.
+ Su almacén de datos ya está incluido `permission-v2` en la `capabilities` matriz. V2.2 es aditivo, ya que amplía la versión 2 y no se puede utilizar de forma independiente.
+ Su IDP Lambda está configurado para validar y pasar por V2.2 el formato de ámbito (los ámbitos `?` contienen la sintaxis de consulta).
#### Habilitando V2.2
La ruta de activación depende de si está creando un nuevo banco de datos o actualizando uno existente.
##### Nuevos almacenes de datos
Al crear un nuevo banco de datos, `permission-v2.2` añádalo a la `capabilities` matriz en el `Metadata` campo de su [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html):
```
"capabilities": [
"launch-ehr",
"sso-openid-connect",
"client-public",
"permission-v2",
"permission-v2.2"
]
```
##### Almacenes de datos existentes
Para habilitar SMART on FHIR V2.2 en un banco de datos existente, agréguelo `permission-v2.2` a la `capabilities` matriz en su `Metadata` campo [https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html](https://docs.aws.amazon.com/healthlake/latest/APIReference/API_IdentityProviderConfiguration.html)y envíe el cambio con `UpdateFHIRDatastore` él. Para obtener más información, consulte [Actualización de un almacén HealthLake de datos](managing-data-stores-update.md).
Requisitos:
+ `permission-v2`debe permanecer en la matriz. V2.2 extiende la V2 y no se puede usar solo.
+ `AuthorizationStrategy`debe ser `SMART_ON_FHIR` (no `SMART_ON_FHIR_V1` o`AWS_AUTH`).
+ La actualización de la configuración del proveedor de identidad la reemplaza por completo, por lo que debe incluir todos los campos y capacidades existentes`permission-v2.2`.
El cambio entra en vigor de forma inmediata, sin tiempo de inactividad. Para verificarlo, busque lo siguiente [Documento de descubrimiento](reference-smart-on-fhir-discovery-document.md) (requiere SigV4):
```
GET {healthlake-endpoint}/r4/.well-known/smart-configuration
```
Si la `capabilities` matriz de la respuesta incluye`permission-v2.2`, SMART on FHIR V2.2 está activo.
#### Sintaxis de ámbito extendido
La gramática de la versión 2 se amplía con una cadena de consulta opcional:
```
V2: (patient|user|system) / resource . cruds
V2.2: (patient|user|system) / resource . cruds [? param=value [& param=value ...]]
```
**V2.2 componentes de la cadena de consulta de alcance**
| Componente | Description (Descripción) |
| --- | --- |
| `?param=value` | Search-parameter filtro. Solo se puede acceder a los recursos que cumplen este criterio. |
| `¶m=value` | Filtro adicional. Se añaden varios filtros y todos deben coincidir. |
Reglas:
+ Los filtros solo se aplican al tipo de recurso especificado en el ámbito. No se admite el uso de caracteres comodín (`*`) con filtros.
+ Los parámetros deben ser válidos para el tipo de recurso según la configuración de búsqueda del banco de datos (compruebe mediante`GET /r4/metadata`).
+ La cadena de ámbito completo (por ejemplo,`patient/Observation.rs?category=laboratory`) es el valor literal que aparece en la afirmación del parámetro de ámbito y del token `scp` de acceso de OAuth 2.0.
+ URL-encode caracteres especiales según el [RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749) en las solicitudes de autorización (por ejemplo, →). `|` `%7C`
+ Para los parámetros de fecha, número y cantidad, V2.2 admite [comparadores](https://docs.aws.amazon.com/healthlake/latest/devguide/reference-fhir-search-parameters.html#search-comparators) de prefijos (por ejemplo,). `?date=eq2023-01-01` V2.2 también admite modificadores [de parámetros de búsqueda](https://docs.aws.amazon.com/healthlake/latest/devguide/reference-fhir-search-parameters.html#search-parameter-modifiers).
#### Ejemplos de alcance
**V2.2 ejemplos de alcance**
| Alcance | Acceso concedido |
| --- | --- |
| `patient/DiagnosticReport.rs?category=LAB` | Solo `DiagnosticReport` los recursos donde `category` están`LAB`. |
| `patient/Observation.rs?_security=http://terminology.hl7.org/CodeSystem/v3-Confidentiality\|R` | Solo `Observation` recursos con etiqueta de seguridad`Restricted`. |
| `patient/Observation.rs?date=ge2023-01-01` | Solo `Observation` los recursos fechados el 1 de enero de 2023 o posteriores. |
| `patient/Observation.rs?category=laboratory&status=final` | Solo `Observation` los recursos que son de laboratorio y finales. |
| `user/Condition.rs?clinical-status=active` | Solo `Condition` recursos activos. |
#### Comportamiento coercitivo
Cuando un token incluye V2.2 ámbitos, HealthLake aplica filtros por operación:
**V2.2 aplicación por operación**
| Operación | Comportamiento |
| --- | --- |
| Lea (`r`) | Solo tiene éxito si el recurso coincide con todos los filtros de alcance. De lo contrario, devuelve 403. |
| Buscar (`s`) | Los filtros de alcance se intersecan con la consulta. Solo se devuelven los recursos coincidentes. |
| Create/Update (`c`/`u`) | El recurso debe cumplir con los filtros de alcance para poder escribirse. De lo contrario, devuelve 403. |
| Eliminar (`d`) | El recurso de destino debe coincidir con los filtros de alcance. De lo contrario, devuelve 403. |
##### Prioridad del alcance
+ Se V2.2 unen varios ámbitos para el mismo tipo de recurso (O entre ámbitos).
+ Un ámbito V2 más amplio sin filtros (por ejemplo`patient/Observation.rs`) otorga acceso total, independientemente de que haya V2.2 ámbitos más estrechos en el mismo token.
+ V2.2 Los ámbitos de un banco de datos que no `permission-v2.2` estén habilitados se ignoran de forma silenciosa.
#### Limitaciones
Los filtros de V2.2 alcance no admiten lo siguiente:
+ Parámetros de búsqueda compuestos (por ejemplo,`code-value-quantity`).
+ Parámetros de búsqueda encadenados (por ejemplo,`subject:Patient.name=Smith`).
+ `_include`/parámetros `_revinclude` de búsqueda.
+ `$export`/`$davinci-data-export`(Datos masivos): V2.2 los filtros no se aplican; la exportación masiva utiliza ámbitos V2.
+ Tipo de recurso comodín combinado con filtros (por ejemplo, no `patient/*.rs?category=LAB` es válido). Debe especificar un tipo de recurso explícito cuando utilice filtros de parámetros de búsqueda (por ejemplo,). `patient/Observation.rs?category=LAB`
**Resolución de problemas**
| Síntoma | Causa | Fix |
| --- | --- | --- |
| No se reconoce el alcance del token | V2.2 no está activado en el almacén de datos | Compruebe `/.well-known/smart-configuration` y solicite la activación a través de un ticket de soporte. |
| 403 en un recurso que existe | El recurso no coincide con el filtro de alcance | Verifique los valores de los recursos con los parámetros del alcance. |
| Resultados de búsqueda vacíos | El filtro de alcance es más limitado que la consulta | Los resultados son la intersección de los filtros de consulta y alcance. |
| Error `InvalidScope` | Parámetro de búsqueda no válido en el ámbito | Confirme el parámetro mediante `/metadata` CapabilityStatement. |
#### End-to-end ejemplo
Escenario: una aplicación para pacientes solo debería mostrar los resultados de laboratorio finalizados a partir de 2023.
1. El servidor de autorización emite un token con el siguiente alcance:
```
patient/Observation.rs?category=laboratory&status=final&date=ge2023-01-01
```
1. Llamadas de clientes HealthLake:
```
GET {endpoint}/r4/Observation?patient=Patient/123
```
1. HealthLake aplica filtros de alcance. La respuesta contiene solo `Observation` los recursos donde `category=laboratory` Y `status=final` Y`date ≥ 2023-01-01`, aunque el cliente haya solicitado todas las observaciones.