Recepción de tratamientos

Treatment Catalog

Catálogo de verticales ACTIVAS con su hoja de sesión. Lo consume el piso del portal de tratamientos para saber qué campos capturar en cada visita. Antes ese esquema venía horneado en el bundle del portal (el registro TS), así que una vertical dada de alta desde Admin se podía prescribir pero no ejecutar: el modal no tenía qué pintar y el centro veía "vertical no soportada". No lleva datos de paciente ni de plan —es un catálogo de configuración—, pero se sirve autenticado y con los mismos roles que el resto del piso: nada aquí es público.

Treatment Claim

Plan Detail

Detalle de un plan reclamado por este centro: progreso (COMPLETED / totalSessions) e historial navegable de TODAS sus sesiones. Scoping por `target_org_id` (mismo aislamiento que la cola). Alimenta la vista de progreso + historial del workspace.

Request Block Authorization

Solicita a la ARS la autorización de un BLOQUE de N sesiones del plan. Crea, reutilizando la infraestructura existente y en una sola transacción: 1. `CoverageEstimate` del bloque (`quantity=N`, `baseAmount=N*costo`), 2. `InsuranceAuthorization` en estado REQUESTED por el monto del bloque, 3. `ClinicalAuthorizationLink(sourceType="TREATMENT_PLAN", sourceId=plan.id)` que enlaza la autorización al plan. Un plan admite UN bloque vivo a la vez: si ya hay una autorización REQUESTED/APPROVED para el plan → 409 (los estados terminales liberan el plan para un bloque nuevo).

Charge Plan Sessions

Cobra una o varias sesiones de un plan reclamado por este centro (AC #1/#2/#3). Construye un `PatientCharge` PENDING por sesión (flujo de Caja existente), enlazado al plan/sesión, respetando la cobertura ARS del bloque (CR-259): las sesiones cubiertas se atribuyen a la ARS (``insuranceCover`` = costo, ``patientPay`` = 0) y las no cubiertas las paga el paciente. Idempotente por (plan, nº de sesión): re-cobrar una sesión ya cobrada la omite (no duplica).

Plan Block Coverage

Cobertura restante del bloque ARS del plan (AC #4). Scoping por `target_org_id` (mismo aislamiento que el detalle/cola): un centro solo lee la cobertura de sus planes.

Treatment Queue

Sesiones programadas para la fecha (hoy por defecto) de los planes reclamados por este centro. El scoping es por `plan.target_org_id == tenant del operador`: solo se ven las sesiones de planes que ESTE centro reclamó (mismo aislamiento que la cola de `order_reception`, donde `target_org_id` es el punto de enforcement). El nombre del paciente se resuelve desde el expediente LOCAL del centro (el que se adoptó/creó en el claim vía EMPI, `tenant_id == org_id`), no desde el sibling del tenant del doctor: así el piso muestra el `TRT-MRN-…` que el centro acaba de ver y nunca lee una fila de otro tenant. Si el centro aún no tiene expediente local para esa identidad global, cae de vuelta al sibling (referencia soft del plan).

Replace Session

"Reponer" una sesión MISSED: agrega EXACTAMENTE UNA sesión SCHEDULED al final del plan, preservando la meta clínica de completar `totalSessions`. Idempotencia: la sesión MISSED se marca con `replacedBySessionNo` en su `sessionData`; un segundo intento de reponer la MISMA sesión → 409 (no agrega otra). La fecha de la reposición es el siguiente día de cadencia después de la última sesión del plan, reutilizando el generador puro de CR-253 (una sola fecha).

Upsert Session

Registra clínicamente una sesión: marca COMPLETED|MISSED y guarda `sessionData`. UPSERT IDEMPOTENTE keyed por `(planId, sessionNo)` (patrón `WaitingRoomVital @@unique([kind, refId])`): reabrir la misma sesión ACTUALIZA en su sitio, nunca duplica. La sesión normalmente ya existe (se materializó en el claim), pero si por cualquier motivo faltara, se crea — así el contrato "una sesión por (plan, nº)" se sostiene con o sin materialización previa.