nutrition

Registrar cuánto comió el paciente

Anota el consumo de UNA comida entregada — CR-508. EL ORDEN DE LAS COMPROBACIONES es el mismo criterio de siempre: primero lo que no depende del mundo —el porcentaje y el motivo, que son un error de quien manda— y después lo que sí —el estado de la comida y si ya estaba anotada—. Así un `63 %` no se contesta con «esa comida no está entregada», que mandaría a mirar la bandeja cuando el problema estaba en el teclado. 422 Y NO 400 en los rechazos de regla, y con la FRASE dentro: quien lee esto está en la habitación con el paciente delante, y «Sólo se puede registrar el consumo de una comida ya entregada» es accionable donde «estado inválido» no lo es. 409 SI YA ESTABA ANOTADO, diciendo qué hay. Una segunda fila con otro porcentaje dejaría sin respuesta la única pregunta que esta tabla existe para contestar; el conflicto dice lo que ya se guardó para que quien lo lea vea si es lo mismo que iba a escribir.

Bandejas entregadas y su consumo

La lista de trabajo del criterio 3: qué bandejas se entregaron hoy y de cuáles falta anotar. ES LO QUE PERMITE QUE LA PANTALLA DE ENFERMERÍA NO ENTRE EN NUTRICIÓN. Sin esta ruta, quien quiere anotar un consumo tiene que saber el `mealId`, y para saberlo hay que abrir la ficha de nutrición del paciente — que es exactamente lo que el CR pide evitar. SÓLO LAS ENTREGADAS, y no «las de hoy». No es una comodidad de la consulta: es el criterio 5 escrito una segunda vez, en el sitio donde de verdad evita el error. Ofrecer en la lista una comida que el servidor va a rechazar es enseñar un botón muerto, y quien lo pulse creerá que falló la red. **UNA LECTURA NO ESCRIBE NADA.** Ni marca vistas, ni crea filas en blanco, ni cierra avisos: esto se llama cada vez que se abre la pantalla de enfermería. SE ACOTA POR SUCURSAL, UNIDAD Y ASIGNACIÓN — SEC-508-002, y no es una comodidad. Esta ruta devuelve NOMBRE, HABITACIÓN Y CAMA, y se pinta debajo de una lista de tareas que sí respeta esos filtros: sin acotarla, la enfermera de la UCI de la sucursal B que abre su pantalla filtrada ve, justo debajo de sus pacientes, a todos los del centro. El filtro dejaría de filtrar la pantalla en el único panel que enseña datos demográficos. Los tres salen del INGRESO (`Admission.branchId`, `Admission.unitId`) y del paciente (`Patient.assignedUserId`), que es de donde los saca `/v1/nursing/workspace` — la comida no tiene sucursal propia, y dársela sería una segunda verdad sobre dónde está el paciente.

Por qué no comió más: la lista cerrada

Los seis motivos del CR, servidos por el API para que la pantalla no los duplique. Ruta LITERAL: va antes que cualquier `/{id}` que se añada a esta sección, igual que `pending`, `reasons` y `suspended`. Lista cerrada y no texto libre por lo mismo que en los ayunos: «sin apetito», «no tiene apetito» e «inapetencia» tienen que ser el mismo motivo para poder contarlos, y quien escribe va con prisa y con el paciente delante.

Corregir un consumo mal anotado

Cambia el porcentaje de un consumo YA anotado — SEC-508-001. POR QUÉ HACE FALTA. Anotar es un acto de un segundo con el paciente delante y el formulario ya abierto; equivocarse de fila o de porcentaje es cuestión de tiempo. Sin esta ruta, el error era permanente: el índice único impide una segunda fila, el POST contesta 409, y la comida ya salió de la lista de pendientes — así que nadie vuelve a preguntar por ella y el aviso que este módulo existe para levantar queda apagado. Un «100 %, se lo comió todo» sobre una bandeja intacta se convertía en un dato clínico falso que nadie podía tocar. NADA SE BORRA, que es la regla del PRD. La corrección no pisa el pasado a escondidas: el porcentaje y el motivo ANTERIORES quedan escritos en la bitácora (`MEAL_CONSUMPTION_CORRECTED`), y la fila dice quién corrigió y cuándo para que se vea al leerla y no sólo excavando `audit_logs`. SE CORRIGE, NO SE ANULA. No hay forma de dejar la comida «sin anotar» otra vez: eso la devolvería a la lista de pendientes y borraría el hecho de que alguien miró el plato. Quien anotó de más corrige a lo que era; quien anotó la bandeja equivocada corrige las dos. SE CORRIGE LO QUE SE MANDA, NO LO QUE SE CALLA — CQ-2. El motivo y las observaciones sólo se tocan si vienen en el cuerpo. Corregir el porcentaje no puede borrar de paso unas náuseas que nadie ha desmentido; borrarlas hay que pedirlo, mandando `reason: null`.

Entregar una bandeja en la habitación

Coteja la bandeja contra el paciente y, sólo si cuadra, la entrega. Responde **200 siempre**, con `outcome`. Lo llama un móvil en un pasillo, y distinguir «bandeja equivocada» de «se cayó la red» es justo lo que hace falta: un 4xx los mezclaría y la reacción a los dos casos es opuesta. **El intento fallido se registra igual.** Es la mitad del CR.

Bandejas en ruta

Lo que va en el carro y todavía no se ha entregado. EL REPARTO EMPIEZA POR LA HABITACIÓN, NO POR LA ETIQUETA. Quien reparte está delante de una puerta: elige a quién le toca y después lee la bandeja que trae en la mano. Empezar por el código obligaría a leer una etiqueta para averiguar a qué habitación hay que ir, que es el recorrido al revés. OJO AL ORDEN: `/deliveries/pending` es literal y va ANTES que cualquier `/deliveries/{id}`.

Qué comidas afectaría cambiar la dieta

Lo que pasaría si se cambiara la dieta AHORA. **No escribe nada.** Existe porque enterarse después no sirve de mucho: quien va a cambiar una dieta a las 11:34 tiene que poder ver, antes de pulsar, que el almuerzo ya está emplatado y que hay una bandeja en el carro. Es la misma pregunta que responde la respuesta de prescribir, hecha antes. Es una RUTA LITERAL y no `/{admission_id}/algo`: el ingreso viaja como parámetro de consulta justo para no tener que pelearse con el orden de las rutas — `pending` y `reasons` ya obligaron a poner los segmentos literales por delante dos veces en este mismo fichero.

Prescribir dieta

Prescribe la dieta y cierra la anterior. LA COMPUERTA: si algún tipo es de riesgo, la orden nace `PENDING_VALIDATION` y NO alimenta a la cocina hasta que el nutricionista la valide. El resto nacen `ACTIVE` de inmediato — hacer esperar a todas parecería más seguro y significaría que un sábado de madrugada, sin nutricionista de guardia, el paciente no come.

Dietas pendientes de validar

La bandeja del nutricionista. OJO AL ORDEN: `pending` es un segmento LITERAL y va ANTES que `/{admission_id}`, o lo captura el parámetro y responde «no encontrada» para una admisión que se llama «pending». Ya pasó con `/loinc-gaps` y con `allergies/food`.

Historial de dietas del ingreso

Incluye las cerradas y las canceladas: un historial que esconde lo que se deshizo no sirve para reconstruir un día, que es para lo único que se mira un historial.

Validar una dieta de riesgo

El nutricionista da por buena la dieta y ESA es la que empieza a alimentar. Validar una orden que ya no está pendiente no es un error benigno: significa que quien valida está mirando una pantalla vieja, y dejarlo pasar convertiría la validación en un gesto sin efecto. Se rechaza y se dice en qué estado está.

Las restricciones que se pueden marcar

Lista cerrada, servida por el API para que la pantalla no la duplique. Duplicarla en el portal garantizaría que un día digan cosas distintas — y la que manda es ésta, porque es la que valida el alta.

Despachar un carro

Registra el carro y mueve sus bandejas a `DISPATCHED`. **Lo que no puede salir se OMITE y se informa, en vez de tumbar el lote.** Si una bandeja de veinte ya la despachó otro, mandar las otras diecinueve de vuelta a la cocina sería peor que el problema — y quien empuja el carro no puede resolver un error de veinte líneas.

Bandejas listas para salir

Las bandejas preparadas, agrupadas por piso y habitación. OJO AL ORDEN: `pending` es literal y va antes que cualquier `/{id}` que se añada aquí.

Ingresados y su dieta

Los ingresados del centro, con su ubicación resuelta. Una sola consulta con los `LEFT JOIN` de ubicación: son decenas de filas, pero la cola de cocina va a llamar a lo mismo por cada turno y no tiene sentido pagar una consulta por paciente para pintar la habitación. `LEFT` y no `INNER` a propósito: un paciente admitido al que todavía no le han asignado cama tiene que salir en la lista igual. Es de los que más urge decidir si come.

La cola de producción de cocina

Lo que hay que cocinar hoy, con lo que hace falta para cocinarlo y nada más.

Horarios de comida del centro

Los seis horarios, con lo guardado pisando a lo por defecto. Devuelve siempre los seis aunque el centro no haya configurado ninguno: es lo que permite que el módulo funcione el día que se contrata, sin obligar a pasar por una pantalla de ajustes antes de poder dar de comer a nadie.

Guardar los horarios del centro

Guarda de golpe los horarios que lleguen. `MANAGE` y no `UPDATE`: cambiar a qué hora come un hospital entero no es trabajo de turno, es configuración del centro. Enfermería y cocina lo LEEN —lo necesitan— pero no lo cambian. **Cambiar un horario no toca ninguna comida ya generada**, y eso es estructural y no una promesa: las comidas del día (CR-499) leerán los horarios EN EL MOMENTO de generarse, así que aquí no hay ninguna cascada que disparar. Cuando exista esa generación, la prueba de esta propiedad vive allí, que es donde podrá comprobarse de verdad.

Comidas de un día

Las comidas del centro para un día, o las de un ingreso. Ordenadas por la hora en que toca servirlas: es la secuencia en que se prepara el día, y devolver el orden del índice dejaría la cocina siguiendo un criterio que cambia solo.

Generar las comidas del día

Crea las comidas que falten. **Es idempotente**: llamarla dos veces no duplica nada. Se puede llamar sin miedo desde donde haga falta —al prescribir, al abrir cocina— porque no reescribe lo que ya existe. Cambiar la dieta de un paciente cuya comida ya está creada NO la modifica aquí: eso es un reemplazo, tiene nombre y tiene su propio CR.

Mover una comida de estado

Avanza la comida, validando la transición contra `meal_state`. El 409 con el mensaje de la máquina no es un formalismo: en una cocina hay varias tablets mirando la misma cola, y quien pulsa «iniciar» sobre algo que otro ya preparó necesita saber QUÉ pasó, no un «error». Por eso el mensaje enumera a dónde sí se podía ir.

La etiqueta de la bandeja

Indicar ayuno

Indica el ayuno y corta las comidas alcanzadas en la misma transacción. Se devuelve QUÉ LE PASÓ A CADA COMIDA, no un «ok». Quien indica un ayuno para una cirugía necesita ver en el acto si llegó tarde a algo: una bandeja ya en el carro no la para este endpoint, y saberlo es lo que le hace descolgar el teléfono.

Los motivos de ayuno que se pueden indicar

La lista cerrada, servida por el API para que la pantalla no la duplique. OJO AL ORDEN: `reasons` es literal y va ANTES que `/npo/{admission_id}`.

Ayunos de un ingreso

Del más reciente al más antiguo. Nada se borra: «¿por qué no cenó el martes?» es la pregunta que alguien hará.

Terminar un ayuno

Cierra el ayuno. Las comidas siguientes vuelven a generarse con normalidad. NO se reviven las comidas suspendidas. Podría hacerse —la máquina de estados deja volver de `NPO` a `AUTHORIZED`— y sería un error: el almuerzo que no se preparó a las doce no sirve a las cinco de la tarde. Lo que corresponde es generar las que vengan, y eso ya lo hace `meal_generation` sin tocar nada.

Comidas suspendidas del día y su motivo

Lo que no se va a comer hoy, con su motivo. Es una RUTA LITERAL y va antes que cualquier `/{id}` que se añada aquí, igual que `pending`, `reasons` y `diet-change-impact`. LOS CONTADORES SALEN DEL DÍA COMPLETO, antes de aplicar `reason`. Que cambiaran al filtrar los haría inútiles: se miran para saber cómo fue el día, no cómo fue el filtro — mismo criterio que los contadores de la cola de cocina. APARECEN TAMBIÉN LAS DESCOLOCADAS POR TRASLADO, que no están suspendidas: siguen vivas y se van a servir. Están aquí porque es donde alguien mira para entender la merma del día, y una bandeja etiquetada para una habitación que el paciente ya dejó es exactamente eso — o se reimprime la etiqueta, o acaba en la basura. Se distinguen sin ambigüedad por su `status`.

Qué ha comido este ingreso, y quién se lo dio

Reconstruye el día —o la estancia entera— a partir de lo que ya quedó escrito. OJO AL ORDEN DE LAS RUTAS: `timeline` es literal y no choca con nada, pero cualquier `/{param}` que se añada a este router después tiene que ir DEBAJO.

Verificar una bandeja por su QR

Verificar la bandeja es verificar la FIRMA, no leer el número. Un código impreso se puede copiar, teclear mal o quedarse de una bandeja anterior. Una firma HMAC no cuadra si alguien cambió una letra del paciente o de la habitación. Se responde 200 con `valid: false` en vez de un 4xx: esto lo va a llamar un móvil en un pasillo, y distinguir «bandeja equivocada» de «se cayó la red» es justo lo que hace falta.