Acceso a datos sensibles

List Sensitive Access Audit

Quién vio qué dato sensible, de quién y desde dónde. Es la pregunta que hace la Ley 172-13 y que los grants no pueden contestar: un grant dice quién PODÍA, esta tabla dice quién lo hizo. Solo entra aquí el acceso EFECTIVO — los intentos denegados no se registran, para que «quién vio esto» se pueda contestar contando filas.

¿Puede quien pregunta ver esta orden, según el compartimento?

Contesta SÓLO la pregunta del compartimento de datos sensibles, para portales que sirven el dato por su cuenta y no pueden aplicar la regla ellos mismos. Responde **200 con un veredicto**: un código distinto de 200 significa «no se pudo decidir», nunca «denegado».

List Sensitive Definitions

Catálogo de la institución. Por defecto solo lo ACTIVO, que es lo que rige. Las retiradas se piden aparte: siguen existiendo porque explican por qué un acceso de hace un año quedó registrado como sensible, pero no deberían confundirse con las que están en vigor.

Create Sensitive Definition

Update Sensitive Definition

Cambiar una definición. `resourceKey` NO se puede cambiar: es la identidad del recurso y lo que CR-240 va a usar para casar un acceso con su nivel. Renombrarla dejaría los registros de auditoría anteriores apuntando a una clave que ya no existe. Para eso está retirar la definición (`status=INACTIVE`) y crear otra.

List Sensitive Grants

Quién tiene acceso a qué. Por defecto solo lo VIGENTE, que es lo que rige ahora; los revocados y los caducados se piden aparte. Un listado que mezcla los tres obliga a leer una columna de estado para responder «¿quién puede ver esto hoy?», que es la única pregunta que se hace desde esta pantalla.

Create Sensitive Grant

Conceder acceso a un recurso sensible.

Revoke Sensitive Grant

Cortar un acceso antes de que caduque. El corte es inmediato: la vigencia la define `active_sensitive_grants` con `status='ACTIVE'`, así que el siguiente paso por el enforcement ya no ve la fila. No hay caché que invalidar.

Suggest Sensitive Definitions

Qué pruebas del catálogo diagnóstico PARECEN sensibles, y por qué. No crea nada. Devuelve candidatas para que una persona las revise y las dé de alta con `POST /definitions`, que es donde queda el rastro de quién decidió qué. Clasificar automáticamente sería peor que no clasificar: el compartimento falla abierto, así que un falso negativo no avisa de nada, y un falso positivo bloquea una prueba rutinaria en mitad de una urgencia. Las categorías salen de `sensitive_categories.py`, que documenta su base normativa fuente por fuente. **No son un dictamen legal**: son un punto de partida para que lo revise quien deba. **Se mira `diagnostic_catalog_items`, NO el catálogo clínico** — CR-242. La primera versión escaneaba `clinical_catalog_items` y proponía la clave a partir de su UUID, pero `lab_order_items.catalogItemId` tiene FK a `diagnostic_catalog_items`: una fila real no puede llevar un id del catálogo clínico, así que la definición creada desde esa sugerencia no habría casado nunca. Y como el compartimento falla abierto, no habría dado error: habría dado acceso, sin auditar. El catálogo diagnóstico es además el que alimenta de verdad el pedido de análisis, que es de donde sale el dato a proteger. Solo laboratorio. Imágenes queda fuera a propósito: las órdenes de imagen se guardan por `modality` (texto libre) y no por código de catálogo, así que proponer `IMAGING_RESULT_<código>` repetiría el mismo fallo que este CR arregla. Ver `imaging_resource_key`.