Precios y nomenclador
El nomenclador es el conjunto de códigos que un financiador reconoce. El precio es cuánto vale cada código para ese financiador.
Las entidades
| Entidad | Schema | Qué es |
|---|---|---|
Element | configuration | Una práctica (o un insumo). Es el código del nomenclador |
ElementCategory | configuration | Un módulo: agrupación de prácticas con código PAMI (2, 69, 543…) |
SubElementCategory | configuration | Sub-categoría / detalle dentro de un módulo |
Price | configuration | El precio de un elemento para un financiador |
PriceProcess | configuration | El proceso de carga / actualización de precios |
practicaPrecio | pami_billings | Precio del lado de la facturación PAMI |
El financiador es obligatorio
Price.INSURANCEID es columna obligatoria. No existe un precio "a secas": todo precio pertenece a un
financiador.
- Un
Elementtambién lleva su financiador (Insurance), con una relación financiado ↔ global: cada elemento financiado se vincula a un elemento global. - La UI de precios permite filtrar por financiador, ver el financiador como columna y relacionar un financiado con su global desde un modal.
INSURANCES sembrada, todo es "Global"La tabla configuration."INSURANCES" migró vacía en algunos entornos. Sin financiadores cargados, no
hay elementos financiados: todo aparece como Global. Es dato faltante, no bug.
Modalidad de facturación: común vs módulo
Los precios y las prácticas distinguen Común y Módulo. La discriminación es la misma regla del episodio de internación:
- MÓDULO si la credencial tiene cápita activa con
ElementCategory.code = '69'yRESPONSIBLE = 'HOSPITAL POSADAS'. - COMÚN en cualquier otro caso.
Ver Episodios.
Configuración de la práctica por financiador
El motor de reglas agrega una capa de configuración por
financiador sobre cada código, separada del catálogo (PracticeFinancierConfig), justamente porque el
comportamiento cambia según quién pague:
| Atributo | Para qué |
|---|---|
nomenclador | A qué nomenclador del financiador pertenece el código. Es la base de la regla práctica desconocida |
requiereAutorizacion | Si la práctica necesita autorización para ese financiador |
nivelAutorizacion | EPISODIO, PRÁCTICA o AMBOS |
modalidadFacturacion | EXTERNO o CAPITADO. Si es null, la práctica no impone modalidad |
coberturaDias | Cuántos días de estadía respalda y de qué tipo (piso / UTI / UCE / guardia), o si otorga días libres |
sexoPermitido / edad | Restricciones clínicas del código |
activo + vigencia | Si el código está vigente para ese financiador a la fecha |
ELEMENTSEl comportamiento es por financiador, no del código en sí. El mismo código puede requerir autorización en un financiador y no en otro, tener otra cobertura, otra modalidad de facturación o pertenecer a otro nomenclador. Por eso vive en una entidad aparte y no como columnas sueltas en el catálogo.
Ciclo de vida (ABM con vigencia)
Nada se borra físicamente:
- Alta: se crea el código con su configuración y su
vigenciaDesde. - Baja: baja lógica cerrando la vigencia (
vigenciaHasta) o marcandoactivo = false. El histórico se conserva. - Modificación: cambios de parámetros con control de vigencia (versionado).
- Reactivación: reapertura de vigencia de un código dado de baja.
Consecuencia directa: una práctica dada de baja a la fecha de la prestación dispara la regla
PRACTICA_NO_VIGENTE, y un código vigente en un financiador puede estar de baja en otro.
Las pantallas
| Pantalla | Qué hace |
|---|---|
prices | Precios / nomenclador del prestador: filtro por financiador, columna de financiador, relación financiado ↔ global, import |
catalogs | Nomenclador (elementos y categorías) |
rules-practices | Configuración de la práctica por financiador (motor de reglas) |
rules-nomencladores | Nomencladores por financiador (motor de reglas) |
Gotchas
Element.INSURANCEIDes obligatorio al crear. Un alta sin financiador no es válida.- El import de precios trabaja con un solo monto y modalidad Común; las columnas de monto extra están ocultas.
- Agregar la columna de financiador al catálogo requirió
ALTER TABLE+ re-aplicar SPs: es un ejemplo típico de por qué el DDL corre antes que el código. Ver DDL y ops.