[sychus]

Note

TL;DR — Interfaz de la doble firma RUP: botón "Pre-validar" para residentes, panel de firmas del informe y badge con la cantidad de firmas en el punto de inicio. Es opcional, no cambia estados y acompaña al PR de la API.

🎫 Ticket	ninguno (sin key de tracker)
🧭 Tipo	feat — UI de doble firma RUP
💥 Alcance	Pantallas RUP de validación y punto de inicio. El botón "Validar" se oculta únicamente a quien tiene rup:prevalidacion.
🧪 Verificado	manual en la app con usuarios residente y de planta → ✅; ESLint → ✅; build de producción → ⚠️ no ejecutado; sin tests nuevos (el repo no tiene runner de tests operativo, ver notas)

Por qué

Acompaña a la doble firma de la API: el médico residente necesita poder dejar su firma de pre-validación sobre un informe y ver las firmas acumuladas, y el médico de planta necesita saber de un vistazo cuántas firmas tiene una prestación antes de validarla. No cambia el flujo de validación. Diseño en el ADR docs/rup/0001-doble-firma-informe.md del repo api.

Qué cambió

• Pantalla de validación — botón "Pre-validar" visible con rup:prevalidacion (oculto para quien tiene rup:validacion), solo con la prestación en ejecucion. Panel "Firmas del informe" como plex-list (pre-validadores primero, validador al final) con matrícula, documento y fecha, badge con la cantidad de firmas en el título, y acción para quitar una pre-validación (src/app/modules/rup/components/ejecucion/prestacionValidacion.component.ts, .html).
• Botón "Validar" — se muestra como antes de la doble firma y se oculta únicamente a quien tiene rup:prevalidacion sobre el tipo (residente). rup:validacion no es requisito para validar: nunca lo fue, ese permiso habilita validar prestaciones ajenas en el punto de inicio.
• Punto de inicio — badge "N FIRMA(S)" debajo del badge de estado en turnos, sobreturnos y fuera de agenda, con tooltip; visibilidad y continuación de prestaciones pre-validables por residentes, tanto fuera de agenda como por agenda (src/app/modules/rup/components/ejecucion/puntoInicio.component.ts, .html).
• Servicio e interfaces — métodos prevalidarPrestacion, quitarPrevalidacion y getPrevalidacionConfig (tope de firmas desde la API, cacheado), e interfaz IFirmaPrevalidacion (src/app/modules/rup/services/prestaciones.service.ts, src/app/modules/rup/interfaces/prestacion.interface.ts).

Cómo probar

1. Entrar como residente (rup:prevalidacion, sin rup:validacion), crear una prestación y pre-validarla → aparece su firma con matrícula, la prestación sigue en ejecución y en el punto de inicio muestra "1 FIRMA". → ✅ observado
2. Entrar con otro residente, abrir la misma desde "Continuar registro" y pre-validar → se suma su firma, el badge pasa a "2 FIRMAS". → ⚠️ pendiente de re-verificar tras el cambio del 2026-10-31
3. Entrar como médico de planta, abrirla desde el punto de inicio y validarla → quedan las firmas de residentes + el validador. → ✅ observado
4. Entrar como médico sin rup:validacion ni rup:prevalidacion, crear una prestación propia → ve el botón "Validar" (regresión corregida). → ⚠️ pendiente de verificar
5. Quitar una pre-validación desde el panel de firmas → se saca; la prestación sigue en ejecución. → ⚠️ pendiente de re-verificar tras el cambio del 2026-10-31

Automatizado: sin tests nuevos. ESLint → ✅ en los archivos tocados. Build de producción → ⚠️ no ejecutado localmente.

Historial de la revisión

• 2026-10-21 — rol neutral (Pre-validador / Validador), matrícula con el formato del informe, panel de firmas como plex-list, tope de firmas leído de la API.
• 2026-10-31 — feedback de usuarios: (1) se elimina la cola "Pendientes de validación" del punto de inicio, saturaba la pantalla junto con agendas y fuera de agenda; (2) se elimina el estado pendienteValidacion, la prestación sigue en ejecucion y la cantidad de firmas se muestra como badge; (3) se corrige el gate de "Validar": exigir rup:validacion era una regresión que ocultaba el botón a médicos que validaban sus propias prestaciones sin ese permiso.

Riesgo y rollback

• Alcance: solo UI. El único cambio de visibilidad respecto de master es que "Validar" se oculta a quien tiene rup:prevalidacion. La validación de internación va por otro flujo y no se toca.
• Migraciones: ninguna.
• Feature flag: ninguno; los botones aparecen según permisos.
• Rollback: revertir el PR.

Notas para el revisor

Tip

Empezá por: los getters puedeValidar / puedePrevalidar en prestacionValidacion.component.ts, y los badges de firmas en puntoInicio.html.

• Requiere el PR de la API (andes/api, misma feature): RUP - Doble firma: pre-validación de informes api#2332. Si la API no tiene el cambio, la pre-validación falla en el PATCH.
• Sobre los tests: el repo no tiene runner operativo (karma.conf.js referencia angular-cli/plugins/karma, no hay karma en devDependencies ni src/test.ts). Levantar la infraestructura queda para un PR aparte; el primer test real debería cubrir la regla de puedeValidar.
• Los filtros del punto de inicio contemplan pre-validación además de "creador o validación"; ver el principio general de gateo en el ADR.

[Silgabgar]

Dejo sugerencias y consultas.

1. Identificación de los profesionales: Nos gustaría que esta funcionalidad pueda utilizarse también en otros escenarios, por lo que sugerimos no hacer la distinción entre médico de planta y residente, sino mostrar los datos de matriculación de cada profesional que firma la prestación.

En caso de que sea necesario diferenciar a un residente de un médico de planta, ¿de dónde se obtendría esa información? ¿Cómo se identificaría esa condición dentro del sistema?

2. Acciones de firma y guardado: Proponemos reemplazar el botón “Pre-validar” por “Firmar” y mostrar, en la misma pantalla, los botones “Guardar” y “Firmar”, permitiendo guardar una prestación sin necesidad de firmarla.

3. Visualización de prestaciones pendientes de validación:
   ¿Todos los profesionales que tengan permisos sobre la prestación podrán visualizarla en el listado de pendientes de validación?
   ¿Cómo se diferenciarán las prestaciones que un profesional tiene en ejecución y pendientes de validar de aquellas que ya cuentan con registros y firmas previas de otros profesionales, por ejemplo, residentes?

[sychus]

Dejo sugerencias y consultas.

1. Identificación de los profesionales: Nos gustaría que esta funcionalidad pueda utilizarse también en otros escenarios, por lo que sugerimos no hacer la distinción entre médico de planta y residente, sino mostrar los datos de matriculación de cada profesional que firma la prestación.

En caso de que sea necesario diferenciar a un residente de un médico de planta, ¿de dónde se obtendría esa información? ¿Cómo se identificaría esa condición dentro del sistema?

2. Acciones de firma y guardado: Proponemos reemplazar el botón “Pre-validar” por “Firmar” y mostrar, en la misma pantalla, los botones “Guardar” y “Firmar”, permitiendo guardar una prestación sin necesidad de firmarla.
3. Visualización de prestaciones pendientes de validación:
   ¿Todos los profesionales que tengan permisos sobre la prestación podrán visualizarla en el listado de pendientes de validación?
   ¿Cómo se diferenciarán las prestaciones que un profesional tiene en ejecución y pendientes de validar de aquellas que ya cuentan con registros y firmas previas de otros profesionales, por ejemplo, residentes?

@Silgabgar

1. No se hace distinción entre tipos de medicos, es simplemente un permiso y es 100% conceptual, para simplificar su uso la idea fue usar un permiso rup:prevalidacion para aquellos profesinonales que participen del informe pero que no tengan el permiso de validar. Es importante que aquellos que tengan este permiso no posean el de validar.
2. Este punto va en contra de lo que solcito por los servicios intermedios, el acto de pre validar conlleva la firma: nombre + apellido + matricula etc. y pidieron especificamente que se llame asi. Eso esta en el documento ADR.
3. • La cola dedicada "Pendientes de validación" (en el punto de inicio) la ven solo los profesionales con rup:validacion: sobre esa prestación, es decir los médicos de planta que pueden validarla. Un residente, que tiene rup:prevalidacion pero no rup:validacion, no la ve en esa cola. Es un atajo pensado para que el validador encuentre lo que espera su firma.

• El listado general "fuera de agenda" sí muestra esas prestaciones pendientes a quien pueda trabajarlas: el creador, un validador o un pre-validador (residente). Por eso el residente las ve ahí, para poder abrirlas y seguir pre-validando. O sea, la visibilidad no depende de "tener permisos sobre el tipo de prestación" en general, sino de tres condiciones concretas: ser el creador, tener permiso de validación, o tener permiso de pre-validación. Un profesional con el tipo habilitado pero sin ninguna de esas tres no la ve en los listados.

Con respecto a ¿Cómo se diferencian las que están en ejecución de las que ya tienen registros y firmas previas de otros profesionales (residentes)?

Por el estado, que es el discriminador de primera clase (indexable y filtrable):

• ejecucion: en curso, sin firmas de pre-validación.
• pendienteValidacion: ya tiene al menos una firma previa de un residente y está esperando validación. La transición a este estado la dispara la primera pre-validación; si se quitan todas las firmas, vuelve a ejecucion.

Visualmente, la cola "Pendientes de validación" muestra en cada ítem un badge con la cantidad de firmas (N firma(s)), así el validador ve de un vistazo cuántos residentes ya firmaron. Y al abrir la prestación, el panel de firmas del informe detalla cada firma: profesional, rol (residente / médico de planta), matrícula y fecha.

[Silgabgar]

Dejo sugerencias y consultas.

1. Identificación de los profesionales: Nos gustaría que esta funcionalidad pueda utilizarse también en otros escenarios, por lo que sugerimos no hacer la distinción entre médico de planta y residente, sino mostrar los datos de matriculación de cada profesional que firma la prestación.

En caso de que sea necesario diferenciar a un residente de un médico de planta, ¿de dónde se obtendría esa información? ¿Cómo se identificaría esa condición dentro del sistema?

2. Acciones de firma y guardado: Proponemos reemplazar el botón “Pre-validar” por “Firmar” y mostrar, en la misma pantalla, los botones “Guardar” y “Firmar”, permitiendo guardar una prestación sin necesidad de firmarla.
3. Visualización de prestaciones pendientes de validación:
   ¿Todos los profesionales que tengan permisos sobre la prestación podrán visualizarla en el listado de pendientes de validación?
   ¿Cómo se diferenciarán las prestaciones que un profesional tiene en ejecución y pendientes de validar de aquellas que ya cuentan con registros y firmas previas de otros profesionales, por ejemplo, residentes?

@Silgabgar

1. No se hace distinción entre tipos de medicos, es simplemente un permiso y es 100% conceptual, para simplificar su uso la idea fue usar un permiso rup:prevalidacion para aquellos profesinonales que participen del informe pero que no tengan el permiso de validar. Es importante que aquellos que tengan este permiso no posean el de validar.
2. Este punto va en contra de lo que solcito por los servicios intermedios, el acto de pre validar conlleva la firma: nombre + apellido + matricula etc. y pidieron especificamente que se llame asi. Eso esta en el documento ADR.
3. • La cola dedicada "Pendientes de validación" (en el punto de inicio) la ven solo los profesionales con rup:validacion: sobre esa prestación, es decir los médicos de planta que pueden validarla. Un residente, que tiene rup:prevalidacion pero no rup:validacion, no la ve en esa cola. Es un atajo pensado para que el validador encuentre lo que espera su firma.

• El listado general "fuera de agenda" sí muestra esas prestaciones pendientes a quien pueda trabajarlas: el creador, un validador o un pre-validador (residente). Por eso el residente las ve ahí, para poder abrirlas y seguir pre-validando. O sea, la visibilidad no depende de "tener permisos sobre el tipo de prestación" en general, sino de tres condiciones concretas: ser el creador, tener permiso de validación, o tener permiso de pre-validación. Un profesional con el tipo habilitado pero sin ninguna de esas tres no la ve en los listados.

Con respecto a ¿Cómo se diferencian las que están en ejecución de las que ya tienen registros y firmas previas de otros profesionales (residentes)?

Por el estado, que es el discriminador de primera clase (indexable y filtrable):

• ejecucion: en curso, sin firmas de pre-validación.
• pendienteValidacion: ya tiene al menos una firma previa de un residente y está esperando validación. La transición a este estado la dispara la primera pre-validación; si se quitan todas las firmas, vuelve a ejecucion.

Visualmente, la cola "Pendientes de validación" muestra en cada ítem un badge con la cantidad de firmas (N firma(s)), así el validador ve de un vistazo cuántos residentes ya firmaron. Y al abrir la prestación, el panel de firmas del informe detalla cada firma: profesional, rol (residente / médico de planta), matrícula y fecha.

@sychus

1. Los permisos de pre-validación y validación son mutuamente excluyentes?, no podrían asignarse simultáneamente a un mismo usuario? - Por otro lado, qué sucede con ese permiso cuando el residente obtiene matricula de especialista? cuales son las condiciones de modificación o revocación del permiso.

2. Con respecto a: la visibilidad no depende de "tener permisos sobre el tipo de prestación" en general, sino de tres condiciones concretas: ser el creador, tener permiso de validación, o tener permiso de pre-validación.
   No me queda claro dado que actualmente para ver o crear una prestación si o si tenés que tener permisos para la prestación en RUP.

3. Por ultimo para confirmar, "Pendiente de Validación" sería un estado nuevo en la interfaz de RUP?

[sychus]

Dejo sugerencias y consultas.

1. Identificación de los profesionales: Nos gustaría que esta funcionalidad pueda utilizarse también en otros escenarios, por lo que sugerimos no hacer la distinción entre médico de planta y residente, sino mostrar los datos de matriculación de cada profesional que firma la prestación.

En caso de que sea necesario diferenciar a un residente de un médico de planta, ¿de dónde se obtendría esa información? ¿Cómo se identificaría esa condición dentro del sistema?

2. Acciones de firma y guardado: Proponemos reemplazar el botón “Pre-validar” por “Firmar” y mostrar, en la misma pantalla, los botones “Guardar” y “Firmar”, permitiendo guardar una prestación sin necesidad de firmarla.
3. Visualización de prestaciones pendientes de validación:
   ¿Todos los profesionales que tengan permisos sobre la prestación podrán visualizarla en el listado de pendientes de validación?
   ¿Cómo se diferenciarán las prestaciones que un profesional tiene en ejecución y pendientes de validar de aquellas que ya cuentan con registros y firmas previas de otros profesionales, por ejemplo, residentes?

@Silgabgar

1. No se hace distinción entre tipos de medicos, es simplemente un permiso y es 100% conceptual, para simplificar su uso la idea fue usar un permiso rup:prevalidacion para aquellos profesinonales que participen del informe pero que no tengan el permiso de validar. Es importante que aquellos que tengan este permiso no posean el de validar.
2. Este punto va en contra de lo que solcito por los servicios intermedios, el acto de pre validar conlleva la firma: nombre + apellido + matricula etc. y pidieron especificamente que se llame asi. Eso esta en el documento ADR.
3. • La cola dedicada "Pendientes de validación" (en el punto de inicio) la ven solo los profesionales con rup:validacion: sobre esa prestación, es decir los médicos de planta que pueden validarla. Un residente, que tiene rup:prevalidacion pero no rup:validacion, no la ve en esa cola. Es un atajo pensado para que el validador encuentre lo que espera su firma.

• El listado general "fuera de agenda" sí muestra esas prestaciones pendientes a quien pueda trabajarlas: el creador, un validador o un pre-validador (residente). Por eso el residente las ve ahí, para poder abrirlas y seguir pre-validando. O sea, la visibilidad no depende de "tener permisos sobre el tipo de prestación" en general, sino de tres condiciones concretas: ser el creador, tener permiso de validación, o tener permiso de pre-validación. Un profesional con el tipo habilitado pero sin ninguna de esas tres no la ve en los listados.

Con respecto a ¿Cómo se diferencian las que están en ejecución de las que ya tienen registros y firmas previas de otros profesionales (residentes)?
Por el estado, que es el discriminador de primera clase (indexable y filtrable):

• ejecucion: en curso, sin firmas de pre-validación.
• pendienteValidacion: ya tiene al menos una firma previa de un residente y está esperando validación. La transición a este estado la dispara la primera pre-validación; si se quitan todas las firmas, vuelve a ejecucion.

Visualmente, la cola "Pendientes de validación" muestra en cada ítem un badge con la cantidad de firmas (N firma(s)), así el validador ve de un vistazo cuántos residentes ya firmaron. Y al abrir la prestación, el panel de firmas del informe detalla cada firma: profesional, rol (residente / médico de planta), matrícula y fecha.

@sychus

1. Los permisos de pre-validación y validación son mutuamente excluyentes?, no podrían asignarse simultáneamente a un mismo usuario? - Por otro lado, qué sucede con ese permiso cuando el residente obtiene matricula de especialista? cuales son las condiciones de modificación o revocación del permiso.
2. Con respecto a: la visibilidad no depende de "tener permisos sobre el tipo de prestación" en general, sino de tres condiciones concretas: ser el creador, tener permiso de validación, o tener permiso de pre-validación.
   No me queda claro dado que actualmente para ver o crear una prestación si o si tenés que tener permisos para la prestación en RUP.
3. Por ultimo para confirmar, "Pendiente de Validación" sería un estado nuevo en la interfaz de RUP?

@Silgabgar
1- Son excluyentes ya que no tendria sentido tener ambos ya que el medico especialista es el unico que puede validar y no tiene sentido que pre-valide. Para que querrias tener ambos?
2- No depende unicamente se refiere a la visibilidad del boton.
3- Claro y se puede firmar tanto "en ejecucion" como en "pendiente de validacion", este fue otro requerimiento donde los medicos especialistas querian saber cuando pueden validar y esto ayuda porque garantiza que ya hay al menos un residente que lo firmo.

[AgosLizzi]

1. Teniendo permisos de pre validación no veo el botón. Directamente valido y aparezco como validador(a). Tengo entendido que los permisos son solo desde el gestor (? adjunto video: https://www.awesomescreenshot.com/video/57620893?key=21ff530092b6b2a2708f928087866a15
2. ¿Hay un limite de "residentes" que puedan pre validar? No veo viable la posibilidad de que, por ejemplo, haya más de 3 pre validaciones. ¿Qué sentido tiene? ¿Se puede establecer un límite según residencia?
3. Corregiría el denominante "médico de planta" por profesional matriculado n 333 y residente con su identificación. No se entiende porque en el caso de los residentes aparece la matrícula (de médico, supongo) y en el caso de "medico de planta" no tengo matrícula.
4. Sugiero utilizar un list para registrar las diferentes firmas. También pensando en la posibilidad de que el listado crezca. Se pueden analizar otras opciones de componentes. Adjunto un ejemplo rápido

[sychus]

1. https://www.awesomescreenshot.com/video/57620893?key=21ff530092b6b2a2708f928087866a15

@AgosLizzi me parece que no lo ves porque vos ya tenes permisos de validar y eso esta mal no podes tener ambos, pero no modifique el sistema de permisos para que evite eso porque esta fuera de scope.

Podrias probar en una prestacion que no tengas el permiso de rup:validacion? o quitarselo en esta ?

[sychus]

@AgosLizzi gracias por la revisión, voy punto por punto:

1. Permiso de pre-validación y validación directa: correcto, es el comportamiento esperado: si tenés rup:validacion sobre el tipo de prestación, no ves Pre-validar y validás directo. Además ahora la API rechaza la pre-validación de un usuario que tenga los dos permisos, así que la exclusión ya no depende solo de la UI. Que el gestor permita asignar ambos permisos queda como mejora fuera de este PR.

2. Límite de residentes: sí, hay límite: la API acepta como máximo 4 pre-validaciones por prestación y una sola por profesional, controlado de forma atómica. El valor está en la config de la API y la app lo lee de ahí, así que no está duplicado. Además el botón se oculta si ya firmaste o si se llegó al tope. Un límite por residencia no es posible hoy porque el sistema no modela la residencia, solo el permiso. Si prefieren 3 en vez de 4, es un cambio de config.

3. Rol neutral y matrícula: tenés razón. Saqué "médico de planta"/"residente": ahora se muestra Pre-validador / Validador, y la matrícula de cada pre-validación sale con el mismo formato que el informe impreso, con vigencia, posgrado y matrícula externa. La del validador no aparece en el panel porque hoy la validación no guarda una copia de la matrícula. En el PDF sí aparece. Agregarla en el panel toca el flujo de validación, que en el ADR quedó fuera de esta etapa, así que lo dejo para un próximo PR.

4. Usar una lista: buena idea, lo pasé a plex-list siguiendo tu ejemplo. Cada pre-validación mantiene el botón para quitarla, y la fila del validador no lo tiene, porque romper la validación es otra acción. Probándolo encontré un caso que no estaba cubierto: al romper una validación, las firmas de los residentes quedaban en la prestación y no se podían quitar. Ahora se limpian al volver a ejecución. Quedan en el historial y los residentes vuelven a pre-validar si corresponde.

re-review