# Modelo de consentimiento y acceso

> Quién ve qué: aislamiento de proyectos, identificadores por pares, concesiones, propiedad de escritura, procedencia y lo que el paciente ve sobre cada aplicación con acceso.

Source: https://developers.anpheros.com/es/guides/consent

**Regla:** con el consentimiento del paciente, una organización ve el registro completo —incluyendo lo que otras clínicas escribieron— pero solo puede cambiar o eliminar lo que ella misma escribió. Cada versión de cada recurso registra el proyecto que lo escribió y la organización en cuyo nombre se escribió.

## Quién ve qué
- Un **proyecto** (clave API) ve los pacientes que ha creado. Bajo una **concesión** (token OAuth), una aplicación ve exactamente un paciente, a través de todos los escritores, limitado a los ámbitos concedidos y a los filtros de categoría. Todo lo demás devuelve 404, nunca 403, por lo que los IDs no se pueden sondear.
- **IDs de par:** cada proyecto recibe su propio ID para la misma persona; los IDs internos nunca salen de la plataforma. Las referencias a pacientes fuera de su ámbito se enmascaran con un token opaco, por proyecto.
- **Directorio** (Organización, Profesional, Rol de Profesional): legible por ID en todo el plano para que las referencias se resuelvan; solo se puede buscar dentro de su proyecto; utilizable como `X-Anpheros-Acting-As` / `X-Anpheros-On-Behalf-Of` solo cuando es suyo.
- **Sandbox y producción** son bases de datos diferentes. Una clave de sandbox físicamente no puede acceder a pacientes reales.

## Escrituras y propiedad
- `project_id` en cada versión de recurso = el escritor. Actualizar/eliminar por otro proyecto → 403 con una explicación; escribe tu propio recurso en su lugar.
- `Provenance.agent.onBehalfOf` = la clínica/organización en el momento de la escritura: `X-Anpheros-On-Behalf-Of`, de lo contrario la organización del PractitionerRole actuante, de lo contrario la organización del proyecto.
- Cada escritura produce un recurso Provenance y una fila de auditoría (quién, qué, cuándo, bajo qué concesión, qué aplicación, desde qué huella digital de origen).

## Lo que ve el paciente
`/me/patients/{id}/grants` enumera cada aplicación con acceso, sus alcances y fecha de caducidad; `…/access-log` enumera lo que cada uno leyó o escribió — bajo el consentimiento **y** con la clave propia del proyecto. La revocación surte efecto en la próxima solicitud; la aplicación no puede volver a conectarse.
Con `format=fhir`, el registro de acceso se devuelve como un Bundle de recursos FHIR R4 `AuditEvent`, con el formato de los Patrones de Registro de Auditoría Básica de IHE (tipo `rest`, la interacción como subtipo, la aplicación y la persona que actúa a través de ella como agentes, el paciente y el recurso como entidades, sin datos clínicos), de modo que otro sistema pueda fusionarlo en la vista de la persona sobre quién accedió a su registro.

Qué registra cada recurso Provenance y cómo configurarlo: [Explicación de la procedencia de los datos médicos](https://developers.anpheros.com/es/guides/medical-data-provenance).

## SMART Health Links (compartir por QR o enlace)

Una persona puede compartir su registro sin una aplicación intermedia: `POST /me/patients/{id}/shl` crea un
[SMART Health Link](https://hl7.org/fhir/uv/smart-health-cards-and-links/) para el subconjunto de **emergencia** (alergias,
medicamentos, problemas, inmunizaciones — sin resultados ni historial) o el Resumen Internacional de Pacientes **completo**, con una contraseña y fecha de caducidad opcionales. La respuesta transporta la URI `shlink:/…` (para un código QR) y una dirección del visor en `/shl/view`, que lo abre en cualquier navegador. Quien lo escanee publica en la URL del manifiesto y recibe el resumen como un JWE (`dir` + `A256GCM`) cifrado con la clave dentro del enlace; cualquier lector de SMART Health Link funciona.

- El contenido se genera en cada apertura (bandera `L`, estado `can-change`), por lo que una tarjeta guardada en el teléfono se mantiene actualizada.
- Una contraseña (bandera `P`) se verifica en el servidor; después de 10 intentos erróneos, el enlace deja de funcionar.
- `GET /me/patients/{id}/shl` lista los enlaces con la frecuencia y cuándo se abrió cada uno; `…/shl/{link}/revoke` desactiva
  uno a la vez. Cada apertura queda registrada en el log de acceso.
- El ID interno de la persona nunca sale de la plataforma: el documento los nombra con un seudónimo del enlace.

## Los agentes de IA proponen, la persona decide

Bajo el consentimiento de una persona, una escritura de un agente de IA (una aplicación registrada como agente, por ejemplo, un asistente conectado a través de MCP) o cualquier escritura con `author_type` `ai` no se aplica de inmediato. La plataforma la valida y responde `202 Accepted` con el ID de la propuesta (encabezado `Anpheros-Proposal`); nada cambia en el registro. La persona lo ve en `GET /me/patients/{id}/proposals` — qué es, qué aplicación lo envió — y lo acepta o rechaza (`…/proposals/{proposal}/accept` o `…/reject`). Una propuesta aceptada se escribe exactamente como se envió, marcada como escrita por IA (HL7 AI Transparency). Los proyectos que pueden ver el registro reciben un webhook delgado `proposal.created`. Las escrituras realizadas con la clave propia de un proyecto, en registros que el proyecto creó, no se retienen.