Autorizaciones (OP)

Una autorización —u OP, Orden de Prestación— es el permiso del financiador contra el que se imputa lo que el prestador hace. Sin autorización válida, la práctica se debita.

Entidad	Schema	Qué es
Authorization	finances	La autorización / OP
AuthorizationDetails	finances	El detalle: qué códigos y qué cantidades se autorizaron
AuthorizationRequest	finances	La solicitud de autorización (previa a tenerla)
AmbulatoryAuthorization	finances	Autorización específica de ambulatorio

Dos orígenes, un solo contrato

Las autorizaciones de un afiliado vienen de orígenes distintos según el financiador:

• PAMI → se scrapean del SII.
• Otros financiadores → no tienen fuente externa; solo están en la base local.

El endpoint by-afiliado tiene que devolver un DTO normalizado en los dos casos. Eso se resuelve con un patrón de adapters:

El discriminador es Insurance.API. Si el financiador tiene un valor ahí, se usa su adapter externo; si es null, cae al adapter de base de datos.

Sumar un financiador con fuente externa

1. Una clase nueva que implemente IAuthorizationAdapter.
2. Registrarla en AuthorizationAdapterRegistry.
3. Setear Insurance.API para ese financiador.

No se toca el controller. Ubicación: src/modules/authorizations/.

Resolución de la credencial

El endpoint acepta la credencial completa o el patientId:

interface FindAuthorizationsByAfiliadoParams {
  credencial?: string;   // credencial COMPLETA: beneficio + grado de parentesco
  patientId?: number;    // alternativa a la credencial
  insuranceId?: number;  // acota al financiador
}

Cada adapter la resuelve a su modo:

• PAMI la parte en beneficio + gp (grado de parentesco).
• La base local la matchea contra PatientAgreement.healthcardnumber.

Hay además soporte de buzón (includeBuzon): trae las autorizaciones de PAMI más las del buzón del prestador.

Alta manual

POST /v1/authorization permite dar de alta una autorización a mano. Es un camino fuera de los adapters: se usa cuando el prestador tiene el papel pero el dato no llegó por el circuito automático.

La bandeja

Pantalla	Qué muestra
authorizations	Bandeja de autorizaciones / OP
authorizations/requests	Solicitudes de autorización

La bandeja muestra, entre otras columnas: motivo y fecha de rechazo, si la autorización es usable y si es de generación propia (EXTERNALGENERATED).

La bandeja excluye las OMEs

Las OMEs se identifican con COMMONREASONID = 1350 y se excluyen de la bandeja de autorizaciones: tienen su propia bandeja y su propio circuito. Ver OMEs y CUP.

Reglas de negocio sobre autorizaciones

El motor de reglas valida, por financiador:

Regla	Qué comprueba
REQUIERE_AUTORIZACION	La práctica exige autorización para ese financiador y no la tiene
ESTADO_AUTORIZACION	La autorización está en un estado válido a la fecha de la práctica
AUTORIZACION_VENCIDA	La autorización está vencida a la fecha de la práctica
CODIGO_PERMITIDO_POR_NIVEL	El código se usó en el nivel correcto: autorización de episodio vs. de práctica
INTERVALO_MAX_FECHAS_AUT	La distancia entre la práctica y la autorización no supera el máximo (medido desde generada o desde activada, configurable)
REUTILIZACION_AUTORIZACION	No se reutiliza más veces de las permitidas: NO_REUTILIZABLE, FIJO (n) o SEGUN_DETALLE
TOPE_CANTIDAD_POR_AUT	La cantidad transmitida no supera la autorizada

Nivel de autorización: por financiador se configura, código por código, si puede autorizarse a nivel EPISODIO (habilita el proceso completo), a nivel PRÁCTICA (va asociada a cada práctica) o AMBOS.

Gotchas

• Authorizations.COMPANYID sin poblar = bandeja vacía para cualquier usuario que no sea SUPERUSER / ADMIN. Es el síntoma clásico de datos sin backfill, no un bug de la query. Ver Multi-tenant.
• EXTERNALGENERATED y CHRONIC son smallint en la DB aunque las entidades los declaren boolean: pasarles un booleano tira 22P02.
• Los resultados del scraping se cachean y deduplican en Redis por número de OP. Si "no se actualiza", mirá las keys de dedup antes de sospechar de la base.