Módulo Banco de Sangre

Análisis de rutas, componentes y flujos del módulo de Banco de Sangre, definidas en src/app/pages/page.routes.ts.

{ path: 'banco/sangre', component: ReceptoresComponent },
{ path: 'documentos/paciente/:id', component: DocspacienteComponent },
{ path: 'productos', component: ProductosComponent },
{ path: 'reacciones/adversas/:id', component: ReaccionesAdversasComponent },
{ path: 'reacciones/transfucionales', component: ReaccionesTransfucionalesComponent },

1. banco/sangre → ReceptoresComponent

Ruta

Ubicación: src/app/pages/receptores/

Qué hace:

Componentes / servicios involucrados:

2. documentos/paciente/:id → DocspacienteComponent

Ruta

Ubicación: src/app/pages/docspaciente/

Qué hace:

Componentes / servicios involucrados:

3. productos → ProductosComponent

Ruta

Ubicación: src/app/pages/censur-productos/productos/

Qué hace:

Componente real: PedidosComponent (src/app/components/censur-pedido/pedidos/)

Componentes / servicios involucrados:

4. reacciones/adversas/:id → ReaccionesAdversasComponent

Ruta

Ubicación: src/app/pages/reacciones-adversas/

Qué hace:

Componentes / servicios involucrados:

5. reacciones/transfucionales → ReaccionesTransfucionalesComponent

Ruta

Ubicación: src/app/pages/admin/reacciones-transfucionales/

Qué hace:

Componentes / servicios involucrados:

Pendiente: comentario // TODO: AGREGAR EL PAGINADOR — la lista no está paginada.

Servicios y dependencias compartidas

ElementoUbicaciónUsado por
PacientesServicesrc/app/services/pacientes/ReceptoresComponent, DocspacienteComponent
BancodesangreServicesrc/app/services/bancodeSangre/DocspacienteComponent, PedidosComponent, ReaccionesAdversasComponent, ReaccionesTransfucionalesComponent
ficha-info-usersrc/app/components/ficha-identificacion/ficha-info-user/DocspacienteComponent, ReaccionesAdversasComponent
app-titulossrc/app/components/ficha-identificacion/titulos/ReceptoresComponent, ReaccionesTransfucionalesComponent
app-pedidos (PedidosComponent)src/app/components/censur-pedido/pedidos/ProductosComponent
CarritoCensursrc/app/clases/carrito-censur/censur-carritoPedidosComponent
buscarReceptorsrc/app/helpers/filterReceptor.tsReaccionesTransfucionalesComponent
NgxSpinnerServicelibrería ngx-spinnertodos los componentes
sweetalert / sweetalert2librerías externasDocspacienteComponent, PedidosComponent

localStorage como puente de estado

En lugar de pasar datos entre rutas mediante un servicio o estado de Angular, el flujo se apoya en localStorage:

ClaveEscrita enLeída en
cede(login / sesión)ReceptoresComponent
idCensurDocspacienteComponent (generaridCensur)PedidosComponent (enviarSolicitud), luego se elimina
censur-carritoPedidosComponent (CarritoCensur)PedidosComponent, luego se elimina
usuario(login / sesión)PedidosComponent (setPedido)

Flujo end-to-end (camino feliz)

ReceptoresComponent (lista de receptores de la sede) │ click en un paciente → /paciente/:id (detalle, fuera de este análisis) │ ... o navegación directa a documentos → ▼ DocspacienteComponent (/documentos/paciente/:id) - Sube 4 documentos obligatorios - Genera receptor en CENSUR → guarda idCensur │ navega a /productos ▼ ProductosComponent → PedidosComponent (/productos) - Selección de productos / carrito - Genera orden de pedido + tipo y cruce │ navega a /dashboard ▼ (tiempo después, tras la transfusión) │ ReaccionesTransfucionalesComponent (/reacciones/transfucionales) - Bitácora de todos los pedidos pendientes/realizados │ click en una fila → /reacciones/adversas/:id ▼ ReaccionesAdversasComponent (/reacciones/adversas/:id) - Registra si hubo reacción adversa - Sube documento de reacción transfusional - Marca receptor como FINALIZADO │ navega a /dashboard ▼ (fin del ciclo del receptor)

Casos de uso

Caso de uso CU-1

Registrar documentos de un receptor nuevo

Actor: Personal de banco de sangre.
Disparador: El receptor fue dado de alta (o ya existe) y necesita iniciar el proceso de solicitud de hemoderivados.

  1. El usuario entra a /banco/sangre y busca/selecciona al paciente.
  2. Navega a /documentos/paciente/:id.
  3. La ficha del paciente se carga automáticamente (ficha-info-user).
  4. El usuario adjunta los 4 documentos requeridos vía dropzone.
  5. Presiona "Guardar":
    • Si hay menos de 4 archivos → se muestra alerta indicando los documentos faltantes (caso de error, ver CU-1a).
    • Si hay 4 o más → se genera el registro en CENSUR (idCensur) y se suben los documentos.
  6. El sistema redirige a /productos.
CU-1a · Camino alterno

Documentación incompleta:

  • El usuario intenta guardar con menos de 4 archivos.
  • Se muestra un modal (Swal.fire) listando los documentos obligatorios faltantes.
  • El usuario permanece en la misma pantalla para completar la carga.
Caso de uso CU-2

Generar pedido de productos sanguíneos

Actor: Personal de banco de sangre.
Precondición: Existe un idCensur válido en localStorage (generado en CU-1).

  1. Tras ser redirigido a /productos, el sistema (PedidosComponent) carga el catálogo de productos disponibles desde el almacén.
  2. El usuario agrega productos al carrito (agregarCarrito), pudiendo eliminar ítems (eliminar).
  3. Presiona "Enviar solicitud":
    • Si el carrito está vacío → alerta de error "Necesitas agregar un producto al carrito" (caso de error, ver CU-2a).
    • Si tiene ítems → se arma el pedido (incluye vendedor y sede desde localStorage.usuario) y el pedidoLab (orden de tipo y cruce).
  4. Se llaman en paralelo generarTypeCruce() y generarOrdenReceptor().
  5. Se muestra alerta de éxito, se limpia localStorage (idCensur, censur-carrito) y se redirige a /dashboard.
CU-2a · Camino alterno

Carrito vacío:

  • El usuario presiona "Enviar solicitud" sin productos en el carrito.
  • Se muestra swal("Necesitas agregar un producto al carrito", {icon:"error"}).
  • El flujo no continúa (no se generan órdenes ni se limpia el storage).
Caso de uso CU-3

Consultar bitácora de reacciones transfusionales

Actor: Personal médico / supervisor.
Disparador: Necesita revisar el estado de los pedidos/receptores y dar seguimiento a posibles reacciones.

  1. El usuario entra a /reacciones/transfucionales.
  2. El sistema carga la bitácora completa (bitacoraReaccionesTransfucionales), filtrando registros sin paciente asociado.
  3. El usuario puede filtrar por nombre del paciente (búsqueda con ≥3 caracteres usando buscarReceptor).
  4. El usuario hace click en un registro → navega a /reacciones/adversas/:id.
Caso de uso CU-4

Registrar reacción adversa y cerrar el caso del receptor

Actor: Personal médico.
Precondición: Existe un pedido/orden asociado al id del receptor (originado en CU-2).

  1. Desde /reacciones/adversas/:id, el sistema carga los datos del paciente vía getOrdenPedidoReceptor(id).
  2. El usuario activa el switch "¿Hubo reacción adversa después de la transfusión?" si aplica (huboReaccion = 'si').
  3. El usuario adjunta el documento "Reacción Transfusional" (dropzone, un solo archivo usado: imagenes[0]).
  4. Presiona "Guardar":
    • Se cambia el estado del receptor a FINALIZADO (cambioEstadoRecpetor).
    • Se adjunta el documento junto con el indicador de reacción adversa (agregarDocumetosReaccionesTransfucionales).
  5. El sistema redirige a /dashboard.
Nota: No hay un caso alterno de validación visible — a diferencia de DocspacienteComponent, aquí se permite guardar aunque no se haya adjuntado ningún archivo (imagenes[0] podría ser undefined).

Observaciones / posibles riesgos detectados