Episodios de atención

Un episodio es una unidad de atención del paciente: una internación o un ambulatorio. En el código es finances.AtentionProcess, una de las entidades más cargadas del sistema (su service ronda las 4.300 líneas).

Anatomía

Concepto	Campo / regla
Tipo	type — 1 = internación, 2 = ambulatorio
Abierto	endDate IS NULL
Credencial vigente	PATIENTAGREEMENTID → PatientAgreement
Financiador	Derivado: AtentionProcess → PatientAgreement → Agreement → Insurance
Centro médico	HEALTHCENTERID — ver Centro médico activo
Empresa	COMPANYID — ver Multi-tenant
Facturado	BILLED — la entidad lo declara boolean, la DB es smallint
Episodio padre	sourceAtentionProcess — el proceso origen en una internación dividida

No busques insuranceId en el episodio

El financiador no es una columna del episodio. Se deriva por la cadena de la credencial. Cualquier filtro o columna "por financiador" en una bandeja de episodios es un JOIN o una subconsulta.

Ciclo de vida

El cierre lleva un motivo de egreso (OUTPUTREASON). El motivo importa para el negocio: hay reglas de validación que ajustan el porcentaje del módulo según el motivo (p. ej. defunción).

Cerrar por borrado de credencial

Si se elimina la credencial vigente de un episodio abierto, el episodio se cierra con un motivo específico de remoción de credencial. Ver Pacientes y credenciales.

Internación: MÓDULO vs COMÚN

La modalidad de facturación de una internación se decide así:

Se evalúa contra la cartilla local del paciente (PatientAgreementElementCategory), no contra las cápitas que PAMI informa.

La comparación de RESPONSIBLE es literal

RESPONSIBLE es texto libre. Un typo, un espacio de más o una diferencia de mayúsculas hace que un episodio que debía facturarse como MÓDULO se facture como COMÚN, y al revés. Está implementado en AtentionProcessService, en el SP finances.SP_get_episode_metrics y en el SP configuration.generar_transmision_internacion: si cambia la regla, hay que cambiarla en los tres lugares.

Internación dividida

Una internación puede dividirse en varios procesos: cambios de servicio, de sector o de modalidad generan un episodio nuevo que apunta al anterior.

• sourceAtentionProcess es el proceso padre (el origen de la división), no el hijo.
• La bandeja marca los episodios divididos con un badge y ofrece un modal con las internaciones vinculadas.

Ocupación de camas y días de estadía

finances.HospitalBedOccupancy registra la ocupación. Los días de estadía son la base de varias reglas de validación:

Concepto	Qué mide
Días respaldados	Los días de cama que las prácticas del episodio respaldan, por tipo (piso, UTI, UCE, guardia)
Días libres	Días de estadía respaldados sin práctica facturable
Días sin cobertura	Días de internación que no están respaldados por ninguna práctica
Días sin prácticas	Días del episodio sin ninguna práctica transmitida

Los cuatro se validan en el motor de reglas.

Diagnósticos y documentación

• finances.PatientDiagnostics — los diagnósticos del episodio. Hay reglas que exigen diagnóstico presente y otras que validan la compatibilidad práctica × diagnóstico.
• finances.Document — documentación adjunta a nivel paciente, episodio o práctica, con árbol de carpetas, tipos administrables y descarga de un PDF combinado.

Las bandejas

Pantalla	Qué muestra
patients/hospitalization/list	Bandeja de internaciones (con segmentación por estado de facturación)
patients/hospitalization/new · /:id	Alta y detalle de internación
patients/ambulatory/list	Bandeja de ambulatorio
patients/ambulatory/new · /:id	Alta y detalle de ambulatorio
patients/ome/list	Bandeja de OMEs — ver OMEs y CUP

Las bandejas filtran por financiador, por empresa y por centro médico activo, y paginan en el servidor. Los detalles de episodio son las pantallas más grandes del sistema: ahí conviven prácticas, insumos, autorizaciones, diagnósticos, documentos y el panel de hallazgos del motor de reglas.

Gotchas

• BILLED es smallint en la DB aunque la entidad lo declare boolean. Pasarle un booleano tira 22P02. Lo mismo pasa con EXTERNALGENERATED y CHRONIC.
• Un episodio sin HEALTHCENTERID desaparece de la bandeja. Cuando se agregó el scoping por centro médico hubo que hacer backfill; sin él, los episodios viejos quedan invisibles.
• La bandeja de autorizaciones excluye las OMEs (COMMONREASONID = 1350): son otro flujo.
• El alta de episodio valida la línea de atención del centro médico contra el backend, no en el front.