Qué es Proteus
Proteus (nombre interno en el código: oxitesa / posadas) es el sistema del lado del
prestador. No es un sistema de PAMI ni un sistema para el afiliado: es la herramienta con la que un
efector de salud gestiona su relación con el financiador.
Los actores
| Actor | Quién es | En el código |
|---|---|---|
| Prestador | "Nosotros". El efector que brinda los servicios (Hospital Posadas / Oxitesa). | Es el sujeto implícito de todo el sistema. En la cartilla local se guarda como texto en RESPONSIBLE |
| Financiador | Quien paga la prestación. PAMI es el principal, pero el sistema es multi-financiador. | configuration.Insurance |
| Afiliado / paciente | La persona beneficiaria de la cobertura. | customer.Patient |
| Empresa (cliente) | El tenant. Proteus sirve a varios prestadores desde la misma base. | configuration.Company — ver Multi-tenant |
| Centro médico | El punto de atención concreto dentro de una empresa. | HealthCenter — ver Centro médico activo |
Aunque PAMI (INSSJP) es el financiador que motiva casi toda la funcionalidad, el modelo de datos es
genérico: precios, autorizaciones y reglas de validación se resuelven por financiador. Cuando
escribas lógica nueva, no asumas PAMI — el discriminador suele ser Insurance.API (ver
Autorizaciones) o la configuración por financiador del
motor de reglas.
Los flujos de negocio
- Pacientes y credenciales — alta del afiliado, sus credenciales por financiador y su cartilla (módulos preasignados). Ver Pacientes y credenciales.
- Episodios de atención — una internación o un ambulatorio, con su credencial vigente y su estado. Ver Episodios.
- Autorizaciones (OP) — el permiso del financiador contra el que se imputa lo que se hace. Ver Autorizaciones.
- Prácticas, insumos y precios — qué se hizo y cuánto vale, según el nomenclador del financiador. Ver Precios y nomenclador.
- OMEs — cada prestación se transmite a PAMI como Orden Médica Electrónica. Solo cuenta si PAMI la valida y valoriza. Ver OMEs y CUP.
- Cápitas y tasas de uso — el modelo de pago: cuánta cápita asignó PAMI y qué porcentaje se cobra según el uso. Ver Modelo de pago capitado.
- Liquidación, transmisión y débitos — la facturación al financiador y sus ajustes. Ver Facturación y débitos.
Atravesando los flujos 3–7 está el motor de reglas por financiador: anticipa los débitos antes de transmitir o facturar, en vez de descubrirlos cuando PAMI los aplica.
De dónde sale el dato externo
Casi todo lo que Proteus sabe del financiador llega por scraping:
| Dato | Origen | Frescura |
|---|---|---|
| Padrón de afiliados, credenciales | SII | Workers de scraping + cache Redis |
| Autorizaciones / OP | SII | Bajo demanda + cache (~12 h) y dedup por número de OP |
| Cápitas asignadas al afiliado | SII → cache Redis | Read-only en Proteus |
| Diagnósticos, planes onco, insumos | SII | Workers |
| OMEs (transmisión y estado) | CUP | Workers |
Detalle técnico en Integración PAMI SII y Workers y colas.
Si PAMI cambia el HTML de una pantalla del SII, el parseo se rompe. La decisión de arquitectura es
dejar crashear el worker (Docker lo reinicia y reintenta) en vez de tragarse el error. No lo
"arregles" envolviendo el loop en un try/catch.
Historia: de qué viene el código
Proteus nació como sistema de home-care y logística de insumos médicos (Oxitesa) y giró a prestador ↔ PAMI. Quedó bastante código del producto viejo, compilando pero sin rutear: remitos, depósitos, vehículos, call center. Está inventariado en Código legacy para que no lo tomes como molde ni pierdas tiempo leyéndolo.