Diseño de pantallas del LIS clínico

Estado: especificación de diseño. Consumidores: Google Stitch (generación de pantallas), diseño de detalle e implementación en Spring Boot + Thymeleaf.

Este documento define el sistema visual y las pantallas de la aplicación de laboratorio clínico. Los requisitos funcionales provienen de procesos, procedimientos, flujos y casos de uso; los nombres de entidades, estados y vistas se toman literalmente del DDL. Todas las pantallas aquí descritas son propuestas de interfaz: ninguna afirma que exista implementación.

Cada pantalla se identifica como S-nn y declara el procedimiento (PO-nn) y los casos de uso (CU-nn) que cubre, de modo que la cobertura funcional sea verificable.

1. Atmósfera y principios

Contexto real de uso. Personal que trabaja de pie, con guantes, lector de código de barras en la mano, interrumpido, en turnos de ocho horas y con presión de tiempo. No es una herramienta que se explore: es una que se opera. El usuario ya sabe qué quiere hacer; la interfaz solo tiene que no estorbar y no dejarlo equivocarse.

Dials. Densidad 9/10 · Varianza 3/10 · Movimiento 2/10.

La densidad alta es una decisión clínica, no estética: un técnico necesita ver veinte pruebas pendientes sin desplazarse. La varianza baja es seguridad: la misma información debe estar siempre en el mismo sitio, turno tras turno. El movimiento bajo es respeto: nada debe desplazarse bajo el cursor de alguien que está a punto de aprobar un resultado.

Estilo base. Minimalismo suizo — retícula estricta, jerarquía por peso y color antes que por tamaño, líneas en lugar de sombras, cero decoración. (Coincidencia verificada en la base de estilos de la skill: «Best For: Enterprise apps, dashboards, professional tools».)

Ocho principios rectores:

1. Identidad visible siempre. Paciente, numero_orden, sede y estado permanecen fijos en cualquier pantalla que pueda afectar una muestra o un resultado. La verificación de identidad se repite ante la toma, la entrega y la divulgación sensible; no se hereda de la pantalla anterior.
2. Tres estados separados y nunca mezclados. Clínico (prueba_solicitada), de muestra (muestra) y financiero (factura). Una factura pagado no pinta de verde una prueba pendiente.
3. Un bloqueo se explica donde ocurre. Un botón deshabilitado sin causa es un defecto. Junto al control bloqueado va la razón concreta —«equipo QUIM-02 bloqueado desde las 09:14 por control rechazado»— y el enlace a resolverla.
4. La versión manda. Toda validación, notificación crítica e informe se muestran atados a una resultado_version numerada. Una versión no vigente se ve en gris con la etiqueta «versión 1 de 3 · reemplazada» y jamás se puede confundir con el valor actual.
5. Motivo antes del hecho irreversible. Rechazar, cancelar, revertir, liberar, corregir, escalar y entregar piden motivo y muestran identificadores concretos en la confirmación, nunca «¿Está seguro?».
6. La ausencia no es normalidad. Una referencia no resuelta se muestra como referencia_no_resuelta, en ámbar, no como resultado normal. Una diuresis sin registrar aparece como «pendiente», nunca como cero.
7. El crítico es una tarea, no un aviso. Vive en una bandeja con responsable, reloj y plazo hasta que queda confirmada o escalada. Un toast no es evidencia de comunicación.
8. Lo sensible se oculta antes de existir. Un resultado sensible no aparece en búsquedas, contadores, vistas previas ni exportaciones de quien no tiene autorización. No basta con tachar el valor: la presencia del dato también se restringe.

2. Color

Neutros Zinc para todo el marco y un solo acento, teal clínico. El rojo, el ámbar y el verde son exclusivamente semánticos: comunican seguridad del paciente y jamás compiten como color de navegación. Todo color va siempre acompañado de texto.

Adaptación declarada. La paleta «Healthcare App» de la base de datos propone primario #0891B2. Medido, ese valor da 3.68:1 con texto blanco: insuficiente para 4.5:1. Se oscurece a #0E7490 (botones) y #155E75 (texto), conservando el matiz de la coincidencia. También se descarta el lienzo cian #ECFEFF de esa entrada: un fondo teñido reduce la salience del rojo y el ámbar, que aquí son señales de seguridad, y cansa en jornadas largas. El lienzo queda neutro.

Todos los ratios anteriores están medidos, no estimados. Verificar de nuevo cualquier par nuevo antes de introducirlo.

Codificación de estado. Cada estado se dibuja con forma + texto + color, nunca con color solo:

La criticidad de un resultado se marca además con un glifo textual delante del valor: ↓↓ para critico_bajo, ↑↑ para critico_alto, ↓/↑ para bajo/alto. Un daltónico debe poder trabajar un turno completo sin perder información.

3. Tipografía

• Interfaz: Atkinson Hyperlegible, pesos 400/700. Es una coincidencia directa de la base de tipografías para contextos sanitarios y está diseñada para desambiguar caracteres de forma inequívoca. En un LIS eso no es una preferencia: confundir 0/O en un lote o 1/l en un código de barras es un incidente.
• Datos: JetBrains Mono 400/500, con cifras tabulares, para código de barras, numero_orden, numero_factura, valores numéricos, unidades, fechas, horas, lotes, versiones y MIC. La densidad 9/10 obliga a monoespaciado en toda cifra alineable.
• Prohibido: Inter, cualquier serif, fuentes de sistema genéricas como tipografía de marca, y ligaduras de programación en la mono (fusionan caracteres y en datos clínicos eso es un riesgo, no un adorno).

Escala (tamaño/interlínea):

Los campos de formulario nunca bajan de 16 px en móvil: por debajo, iOS hace zoom al enfocar y desplaza la pantalla. Los textos de ayuda se limitan a 65 caracteres por línea. Un valor, su unidad y su bandera forman una unidad indivisible: nunca se parten entre líneas.

4. Retícula, espacio y componentes

Retícula. Base de 4 px. Márgenes 16 / 24 / 32 px en móvil / tableta / escritorio. Contenido máximo 1440 px; formularios de una columna, máximo 880 px.

Armazón. Cabecera fija de 56 px con buscador global, sede activa, alertas y cuenta. Navegación lateral de 224 px, colapsable a 56 px de iconos con etiqueta accesible. Barra de contexto de paciente/orden de 48 px, adherida bajo la cabecera en toda pantalla de detalle. El área de trabajo usa scroll-padding-top igual a la suma de las tres, para que el foco de teclado nunca quede tapado.

Dos zonas en pantallas de detalle: contenido principal de 8 columnas y panel contextual de 4 (evidencia, historial, bloqueos). Por debajo de 1280 px el panel pasa a pestañas; por debajo de 768 px todo va a una columna y las tablas anchas se envuelven en un contenedor con desplazamiento horizontal propio — el cuerpo de la página nunca se desplaza en horizontal.

Botones. Un primario sólido por región de decisión, relleno acento, texto blanco, altura 36 px en escritorio y 44 px en táctil. Secundario con borde #71717A. Destructivo con texto y borde #B42318, relleno solo dentro del diálogo de confirmación. Al presionar, desplazamiento táctil de 1 px; sin brillo exterior. Aprobar, rechazar, entregar, escalar y corregir llevan siempre etiqueta de texto visible; nunca son iconos solos.

Tablas densas. Fila de 36 px, cabecera adherida, ordenamiento marcado con flecha y aria-sort, filtros aplicados visibles como chips eliminables, recuento total y paginación con tamaño de página persistente. Columna de selección múltiple cuando existan acciones en lote (distribuir alícuotas, liberar un lote de resultados). Cada fila expone una acción principal visible y un menú de secundarias: ninguna acción vive solo en hover, porque no existe hover en el táctil ni para el teclado.

Campos. Etiqueta encima, ayuda opcional debajo de la etiqueta, error debajo del campo y unido con aria-describedby. Nunca el marcador de posición como etiqueta. Los campos de código de barras se autoenfocan y aceptan la pulsación de retorno del lector.

Superficies. Radio 6 px en controles, 10 px en paneles, 14 px en diálogos. Sombra solo en lo que realmente flota: diálogo, menú superpuesto, panel lateral. Las listas se separan con líneas, no con tarjetas — a densidad 9 las tarjetas desperdician la mitad de la pantalla.

Iconos. Un solo juego de trazo uniforme (Phosphor como principal, Heroicons como alternativa), 20 px en controles. Decorativo junto a texto visible ⇒ aria-hidden="true"; dentro de un control ⇒ el control lleva nombre accesible y expone su estado. Ningún emoji, en ningún sitio.

Estados obligatorios de toda pantalla. Cada vista define cinco: carga (esqueleto con las dimensiones reales de la tabla o del formulario, nunca un disco girando), vacío (qué significa y cuál es la acción para poblarlo), error de carga (causa y reintento), sin permiso (qué rol lo habilita y a quién solicitarlo) y bloqueado (causa concreta y camino de resolución).

5. Movimiento

Movimiento 2/10. Solo cuatro transiciones existen, todas de 120–200 ms con ease-out, todas sobre transform y opacity:

1. Apertura de diálogo y panel lateral: opacidad y 8 px de desplazamiento.
2. Aparición o desaparición de una fila tras una acción en lote: fundido de 150 ms.
3. Barra de progreso determinada en procesos largos (emisión de informe, importación de interfaz).
4. Esqueleto de carga con barrido suave.

Nada más. Sin revelados al desplazar, sin cascadas, sin micro-bucles perpetuos, sin contadores animados: en una pantalla de resultados, un número que cambia solo es indistinguible de un número que cambió de verdad. Bajo prefers-reduced-motion: reduce incluso estas cuatro se resuelven al estado final de inmediato.

Nota sobre la skill de Stitch: su regla de «micro-interacciones perpetuas» y su repertorio de héroe asimétrico están pensados para superficies de marketing. Aquí se aplican únicamente a S-01 Acceso. En el espacio operativo se anulan de forma deliberada; el movimiento perpetuo junto a un valor crítico es un defecto de seguridad.

6. Arquitectura de información

Navegación lateral por función, no por tabla. Se muestran solo las secciones que el rol puede usar; una sección sin permiso no aparece atenuada, no aparece.

Rutas profundas obligatorias. Orden, paciente, muestra, alícuota, prueba solicitada, versión de resultado, informe, cultivo, lote y notificación crítica tienen cada uno su URL estable y compartible. Al volver desde un detalle, la lista conserva filtros, orden, página, tamaño de página y fila seleccionada. Un técnico que abre un resultado y vuelve no debe reconstruir su filtro.

Búsqueda global (/). Acepta número de orden, historia, documento y código de barras, distingue el tipo por patrón y salta directo cuando la coincidencia es única. Respeta la restricción de resultados sensibles: lo que el usuario no puede ver, tampoco se cuenta en los resultados.

7. Catálogo de pantallas

7.1 Acceso y turno

S-01 · Acceso

Cubre: P15. Actor: cualquiera.

Única pantalla con composición asimétrica: dos tercios de contenido a la izquierda, formulario a la derecha, sin centrado. Sin «hero» comercial, sin testimonios, sin desplazamiento. Autenticación por clave de acceso (WebAuthn) como camino principal y contraseña como alternativa. Tras autenticar, si la cuenta tiene varias sedes, se elige la sede activa antes de entrar: la sede condiciona listas de trabajo, equipos e inventario, y equivocarse en ella contamina todo el turno.

Errores de credencial sobre el campo, nunca genéricos arriba. Bloqueo de cuenta explica la causa y a quién acudir.

S-02 · Panel de turno

Cubre: P15, P09. Actor: todos.

Inicio según rol. No es un tablero de métricas de negocio: es una lista de lo que hay que hacer ahora. Cuatro bloques en dos columnas asimétricas (7/5), nunca tres tarjetas iguales en fila:

1. Mi cola — recuento y acceso directo a la bandeja principal del rol (lista de trabajo, validación, toma pendiente, cartera).
2. Requiere atención — críticos sin confirmar con reloj, bloqueos analíticos activos, muestras rechazadas sin resolver, lotes por vencer. Ordenado por gravedad, no por fecha.
3. Tiempos en riesgo — pruebas que superarán su tat_objetivo_minutos, desde v_tiempos_respuesta.
4. Mi sede hoy — órdenes registradas, muestras recibidas, pruebas publicadas. Cifras reales, sin metas decorativas.

Estado vacío del bloque 2: «Sin avisos pendientes en esta sede», no una ilustración celebratoria.

7.2 Pacientes y órdenes

S-03 · Búsqueda de paciente

Cubre: PO-02 · CU-01. Actor: recepción.

Campo único que acepta historia, documento o nombre, con selector de sistema de identificador (identificador_paciente.sistema) para documentos ambiguos. Resultados en tabla densa: historia, nombre completo, fecha de nacimiento y edad calculada, sexo biológico, última orden. Los homónimos se marcan en la propia lista con un aviso ámbar y se obliga a confirmar un segundo dato antes de continuar; es el punto exacto donde nacen los errores de identidad.

Sin coincidencias: la acción es «Registrar paciente», con lo tecleado precargado.

S-04 · Ficha de paciente

Cubre: PO-02 · CU-01, CU-04. Actor: recepción, validador, auditoría.

Cabecera de identidad persistente. Pestañas: Identificadores · Contacto · Coberturas · Consentimientos · Órdenes · Resultados históricos.

sexo_biologico e identidad_genero son campos distintos y así se rotulan, con una nota de que la selección de intervalos de referencia usa el primero. Las coberturas muestran vigencia y estado; el sistema impide solapar plan y aseguradora en el mismo periodo y lo explica en el campo, no como error genérico.

Duplicados. Cuando hay sospecha, un aviso lleva a un comparador de dos columnas. La fusión no es un botón: es una solicitud que exige motivo, deja registro y advierte que la operación no elimina hechos clínicos.

S-05 · Registro de orden

Cubre: PO-02 · CU-02, CU-04. Actor: recepción.

Formulario de una columna en cuatro secciones reveladas progresivamente, con indicador de paso.

1. Contexto — paciente confirmado, médico solicitante, prioridad (rutina / urgente / stat), sede de registro (obligatoria), sedes de toma y proceso, diagnóstico.
2. Servicios — buscador de pruebas y perfiles. Al añadir un perfil se expande a la lista de pruebas con tipo_adicion = 'perfil' y su origen visible; cada línea puede quitarse individualmente. Una prueba ya activa en la orden se marca como duplicada y no se añade. Cada línea muestra su requisito de muestra, su ayuno y su precio vigente.
3. Datos clínicos — solo aparecen los tipo_dato_clinico que las pruebas seleccionadas requieren (peso, talla, gestación, diuresis), con unidad y momento de observación. Un cálculo que los necesita y no los tiene se anuncia aquí, no tres pantallas después.
4. Requisitos — resumen de consentimientos exigibles, preparación, recipientes a rotular y total estimado.

El numero_orden se muestra tras guardar, en monoespaciada, con acción de copiar. Nunca se pide al usuario que lo invente.

Bloqueos visibles: prueba requiere_consentimiento sin consentimiento vigente; prueba sin tarifa vigente para la cobertura elegida; orden sin ninguna prueba.

S-06 · Detalle de orden

Cubre: PO-02 a PO-13 · CU-03, CU-17. Actor: todos los operativos. Es la pantalla central de la aplicación.

Barra de contexto permanente: paciente, historia, numero_orden, prioridad, sede, estado de orden, y una separación explícita de los tres estados —clínico, de muestras, financiero— como tres píldoras rotuladas.

Cuerpo en dos zonas.

Principal: tabla de prueba_solicitada con una fila por prueba y columnas prueba · sección · tipo_adicion · estado · muestra/alícuota · TAT · acción. Cada fila se despliega mostrando sus analitos con valor, unidad, referencia mostrada, bandera y criticidad de la versión vigente. Una prueba derivada muestra el laboratorio de referencia; una en cultivo, la última lectura.

Contextual: cronología unificada de la orden —transiciones, eventos de muestra, ejecuciones, validaciones, notificaciones, informes y entregas— en orden inverso, filtrable por tipo. Es la respuesta a «qué pasó aquí».

Acciones: agregar prueba (CU-03), imprimir rótulos, emitir informe parcial, cancelar prueba con motivo. La cancelación advierte si la prueba ya tiene resultados y qué se conserva.

S-07 · Agregar prueba a una orden

Cubre: PO-02, PO-05 · CU-03. Actor: recepción, técnico.

Diálogo con tres respuestas antes de permitir confirmar: ¿hay muestra reutilizable dentro de su estabilidad?, ¿cuál es la tarifa y la cobertura aplicable?, ¿requiere consentimiento? La muestra candidata se muestra con su hora de toma y el tiempo restante de estabilidad calculado; si venció, la única salida ofrecida es nueva toma. La línea creada queda con tipo_adicion = 'agregada'.

S-08 · Consentimiento

Cubre: PO-02 · CU-04. Actor: recepción.

Alcance (prueba / categoria / divulgacion), código de alcance, otorgante, medio, vigencia y adjunto de evidencia. La lista histórica muestra los revocados tachados con su fecha. Desde aquí se ve qué pruebas de qué órdenes quedan bloqueadas por falta de consentimiento.

7.3 Caja

S-09 · Cotización y cobertura

Cubre: PO-03 · CU-05. Actor: caja, admisión.

Detalle por prueba con precio unitario, descuento y precio final congelados; a la derecha, cobertura vigente, autorización y copago. La aritmética se muestra explícita —subtotal, descuento, impuesto, total— porque el modelo la verifica y una discrepancia debe ser visible, no silenciosa. Una urgencia puede avanzar sin pago: esa decisión se registra con motivo en la misma pantalla, no en un ajuste posterior.

S-10 · Factura y pagos

Cubre: PO-03 · CU-06. Actor: caja.

Cabecera con numero_factura en monoespaciada y estado (pendiente / parcial / pagado / anulado / reembolsado). Tabla de pagos con método, monto, referencia y estado. La reversión no borra: crea una fila reversado enlazada a la original y ambas quedan visibles, con el saldo recalculado debajo. Anular exige motivo y advierte que el documento se conserva.

S-11 · Cartera

Cubre: PO-03. Actor: caja.

cuenta_por_cobrar por aseguradora con monto, pagado, pendiente, estado y antigüedad. Filtro por estado y acciones en lote para marcar envío. Las glosas se destacan en ámbar con su observación visible en la fila, no escondida tras un clic.

7.4 Muestras y custodia

S-12 · Hoja de toma

Cubre: PO-04 · CU-07. Actor: recolector.

Diseñada para pantalla táctil y uso con guantes: controles de 48 px, alto contraste, sin menús anidados.

Paso 1, verificación activa de identidad: el sistema pide teclear o escanear un dato del paciente, no muestra el nombre para que se confirme con un toque. Paso 2, lista de recipientes a tomar, agrupada por tipo de tubo con su color orientativo y volumen mínimo. Paso 3, por cada muestra: escaneo del código de barras, volumen, condiciones, hora. Para muestra temporizada, el formulario de periodo aparece como bloque único —inicio, fin y volumen total juntos— porque el modelo no admite capturarlo por partes, y hasta cerrarlo el cálculo queda «pendiente».

Incidencias de toma se registran en el momento, con la muestra a la vista.

S-13 · Recepción técnica

Cubre: PO-04 · CU-08. Actor: recepción técnica.

Campo de escaneo siempre enfocado; cada lectura añade la muestra a una lista de trabajo. Por muestra: identificación, requisitos esperados frente a lo recibido, temperatura y tiempo de tránsito.

La inspección ofrece las cuatro decisiones del modelo como botones rotulados —rechazar, aceptar_excepcion, nueva_toma, cancelar_prueba— con categoría y descripción obligatorias. La excepción exige además autorizador. Al decidir nueva_toma, la pantalla genera el nuevo código y lo enlaza a muestra_reemplazada_id sin perder la trazabilidad de la rechazada, y ambas quedan consultables.

S-14 · Cadena de custodia

Cubre: PO-04. Actor: técnico, auditoría.

Línea de tiempo vertical de evento_muestra con tipo, sede, ubicación, temperatura, responsable y hora. Solo lectura y así se rotula: «registro inmutable; una corrección se añade como evento nuevo». Si la muestra reemplaza o fue reemplazada por otra, ambas cadenas se muestran enlazadas lado a lado.

S-15 · Mesa de alícuotas

Cubre: PO-05 · CU-09. Actor: recepción técnica, técnico.

Dos paneles. Izquierda: muestras aceptadas sin distribuir. Derecha: pruebas pendientes agrupadas por sección, estabilidad y tipo de muestra.

La pantalla enseña de forma explícita lo que el modelo impone: una prueba llega a su muestra únicamente a través de una alícuota. Al seleccionar una muestra, la acción por defecto es «Crear alícuota», con la opción rotulada «alícuota del tubo primario» cuando no hay separación física real. Cada vínculo declara su propósito (analisis / repeticion / derivacion / conservacion) y una alícuota queda marcada como principal — la interfaz avisa si una prueba queda sin principal, porque entonces aparecería en la lista de trabajo sin muestra identificada.

Una alícuota con estabilidad vencida se muestra en ámbar y no es seleccionable; la única salida ofrecida es nueva toma.

7.5 Calidad

S-16 · Tablero de calidad

Cubre: PO-06. Actor: técnico, calidad.

Matriz equipo × analito con la aptitud vigente de cada cruce: control aceptado, en advertencia, rechazado o bloqueado. Un cruce bloqueado muestra desde cuándo y por qué. Debajo, calibraciones y mantenimientos por vencer.

S-17 · Corrida de control interno

Cubre: PO-06 · CU-10. Actor: técnico.

Captura por nivel contra un lote_control disponible, con valor, media objetivo, desviación y z-score calculado en vivo. A la derecha, carta de Levey-Jennings: línea de tendencia con líneas de ±1s, ±2s y ±3s, el punto fuera de control marcado con forma distinta y anotación de texto, no solo con color. (Tipo de gráfico verificado en la base de la skill: «Anomaly Detection — Line Chart with Highlights»; su nota de accesibilidad exige forma y anotación además del color.) Debajo de la carta, tabla de los mismos puntos, navegable con teclado: es la alternativa accesible obligatoria, no un extra.

Las reglas evaluadas se listan con su veredicto. Clasificar la corrida como rechazada propone abrir el bloqueo en el mismo flujo.

S-18 · Bloqueo analítico

Cubre: PO-06. Actor: calidad.

Causa, alcance (equipo, método, analito), inicio, corrida de control asociada e investigación. Impacto visible: lista de pruebas solicitadas que el bloqueo está deteniendo ahora mismo — un bloqueo sin su costo a la vista se olvida. El cierre exige resolución escrita y un profesional_laboratorio autorizador; ambos campos son obligatorios y así se rotulan.

S-19 · Equipo

Cubre: PO-06, PO-07. Actor: técnico, calidad.

Identificación, sede, sección, estado operativo, interfaz y pruebas habilitadas con vigencia. Pestañas de mantenimiento, calibración y bloqueos. El editor de habilitaciones advierte de solapes de vigencia antes de guardar, porque el modelo los rechaza.

S-20 · Control externo

Cubre: PO-06 · CU-24. Actor: calidad.

Programa, ronda y periodo; por analito, resultado reportado, asignado, grupo par, sesgo, evaluación y acción correctiva. Estado del programa visible en la cabecera.

7.6 Ejecución y captura

S-21 · Lista de trabajo

Cubre: PO-05, PO-07. Actor: técnico. Fuente: v_lista_trabajo.

Tabla densa por sección: prioridad, estado, código de prueba, paciente, historia, muestra, antigüedad frente a tat_objetivo_minutos. Prioridad stat fija la fila arriba con borde izquierdo rojo y la etiqueta escrita. Filtros persistentes por sección, estado, prioridad y equipo. Selección múltiple para asignar a una corrida.

Una fila sin código de barras significa prueba sin alícuota principal: se muestra con aviso ámbar «sin alícuota vinculada» y enlace a S-15, en lugar de una celda vacía inexplicable.

S-22 · Captura de resultados

Cubre: PO-07 · CU-11, CU-12. Actor: técnico.

Cabecera de contexto con paciente, orden, prueba, alícuota, equipo, método y origen (manual / interfaz / calculo / laboratorio_referencia / poct).

Rejilla de analitos, una fila por analito, en el orden de presentación del catálogo: nombre · campo de valor · unidad fija · referencia · bandera · criticidad. El tipo de campo se deriva del analito —numérico, texto, selección codificada o memo— y la unidad no es editable: el modelo exige que coincida con la configurada, así que la interfaz no ofrece la posibilidad de equivocarse. Un analito de título se dibuja como encabezado de grupo sin campo. Los cálculos se muestran de solo lectura con el origen de sus insumos y, si falta un dato clínico, se marcan «pendiente» con el enlace para capturarlo.

Al guardar se crea la versión; desde la versión 2 el motivo es obligatorio y el diálogo lo pide antes de escribir. Repetir abre una ejecución nueva conservando la anterior y las dos quedan comparables.

Atajos: Tab avanza entre analitos, Ctrl+S guarda el borrador, Ctrl+Enter guarda y pasa a la siguiente prueba de la cola. Todos anunciados en un panel de ayuda accesible por teclado.

S-23 · Bandeja de interfaz

Cubre: PO-07. Actor: técnico.

Mensajes por equipo con protocolo, dirección, correlación, hora y estado (recibido / procesado / duplicado / error / cuarentena). Filtro por defecto: cuarentena y error primero, porque son los únicos que requieren persona.

Al abrir un mensaje en cuarentena, dos columnas: contenido recibido a la izquierda, resolución a la derecha —a qué prueba y analito debe mapearse—. Un duplicado muestra con qué mensaje colisionó por correlación. Nunca se ofrece «aceptar sin mapear».

S-24 · Historial de versiones

Cubre: PO-07, PO-10 · CU-12, CU-18. Actor: técnico, validador.

Todas las versiones de un resultado en orden inverso. La vigente arriba, con marca clara; las anteriores en gris con «reemplazada». Por versión: valor, unidad, referencia aplicada, bandera, criticidad, origen, ejecución, autor, fecha, motivo del cambio, validaciones y notificaciones asociadas. Comparación de dos versiones lado a lado con las diferencias resaltadas. Todo de solo lectura, sin excepción.

S-25 · Captura en punto de atención (POCT)

Cubre: PO-14 · CU-23. Actor: operador POCT.

Variante compacta de S-22 para tableta: un analito por pantalla, controles de 48 px, sede POCT y equipo fijados en la cabecera. Origen poct visible y no editable. Un aviso permanente recuerda que el resultado entra al mismo ciclo de referencia, criticidad, validación e informe que uno del laboratorio central; no hay atajo de publicación.

7.7 Validación, críticos e informes

S-26 · Bandeja de validación

Cubre: PO-08 · CU-14, CU-15. Actor: técnico, validador.

Dos pestañas, técnica y profesional, con la misma estructura. Fila por versión pendiente: paciente, prueba, analito, valor con bandera, criticidad, delta disparado, estado de la muestra, aptitud del control de calidad, antigüedad.

Cuatro indicadores por fila resumen si la versión es liberable: muestra conforme · control apto · referencia resuelta · sin criticidad. Un indicador en rojo explica por qué, al pasar el foco y también al abrir. Las filas críticas se separan arriba y no ofrecen aprobación en lote: la aprobación múltiple solo alcanza a las que cumplen los cuatro.

S-27 · Validación de una versión

Cubre: PO-08 · CU-13, CU-14, CU-15. Actor: validador.

Todo lo necesario para decidir, sin abrir otra pantalla:

• Valor con unidad, referencia mostrada, bandera y criticidad, y el intervalo aplicado con sus criterios (analito, método, unidad, sexo biológico, rango de edad, vigencia). Si no hubo coincidencia única, el estado referencia_no_resuelta aparece en ámbar con la lista de intervalos candidatos.
• Antecedentes del paciente para el mismo analito, en una línea de tiempo corta con el delta calculado.
• Reglas ejecutadas desde ejecucion_regla: regla, versión y decisión (no_aplica / cumple / no_cumple / disparada / bloqueada / error).
• Contexto analítico: muestra, no conformidades, ejecución, equipo, control vigente y lotes consumidos.
• Decisiones previas sobre la misma versión, con sus devoluciones.

Acciones: aprobar, devolver con motivo, repetir. Autovalidación: cuando una versión fue liberada por regla, la interfaz lo declara —«liberada automáticamente por regla de autovalidación v3»— con enlace a la evidencia; nunca se presenta como si la hubiera aprobado una persona.

Regla refleja disparada: aviso con la prueba que se creará, su tarifa, su cobertura y si exige confirmación humana. Al confirmarse, la nueva prueba_solicitada queda con tipo_adicion = 'refleja' y enlace a su prueba de origen. Si falta consentimiento, cobertura o muestra apta, queda pendiente y la pantalla lo dice.

S-28 · Bandeja de valores críticos

Cubre: PO-09 · CU-16. Actor: validador.

Cola persistente ordenada por tiempo transcurrido, no por fecha de llegada. Por fila: paciente, prueba, analito, valor con su glifo de criticidad, versión, estado (pendiente / enviada / confirmada / escalada), reloj contra el plazo institucional y responsable asignado. Al superar el plazo la fila pasa a peligro y propone escalar.

Sigue visible fuera de la sección: contador en la cabecera, presente en todas las pantallas.

S-29 · Comunicación de un crítico

Cubre: PO-09 · CU-16. Actor: validador.

Tres bloques secuenciales. Confirmar o repetir el valor. Elegir destinatario autorizado, su relación con el paciente y el canal. Registrar la comunicación: hora, quién recibió, evidencia de lectura.

Cierre únicamente por confirmada o escalada, cada uno con su fecha; la interfaz no ofrece una tercera salida ni permite «cerrar sin acción». El escalamiento pide responsable y acción.

S-30 · Composición de informe

Cubre: PO-10 · CU-17. Actor: validador emisor.

Izquierda, selección: solo versiones vigentes en estado liberada o publicada, agrupadas por sección y prueba, con las no elegibles listadas aparte y su razón escrita. Derecha, vista previa fiel del documento.

Un informe parcial se declara como tal y enumera lo que queda pendiente. Los resultados sensibles se marcan y respetan la autorización de divulgación del destinatario. Al emitir: numero_informe consecutivo, versión, firmante, formato y huella de integridad. El orden de presentación es explícito y sin repeticiones.

S-31 · Entrega de informe

Cubre: PO-10 · CU-17, CU-22. Actor: personal autorizado.

Canal (portal / correo / impreso / hl7 / fhir / otro), destinatario, verificación de identidad de quien recibe y evidencia. La distinción es explícita en la interfaz: una reimpresión genera otra constancia de entrega, no una versión clínica nueva, y el texto del botón lo dice. Historial de entregas debajo, con canal, destinatario y hora.

S-32 · Corrección de informe

Cubre: PO-10 · CU-18. Actor: validador.

Flujo guiado de cuatro pasos con indicador de progreso: identificar la versión y el informe originales → registrar el motivo → crear y validar la nueva versión → emitir el informe sustituto.

Antes de confirmar, la pantalla resume el alcance: qué valor cambia, a quiénes se entregó el informe original y a quiénes hay que notificar. El informe nuevo lleva versión mayor, reemplaza_a_id y motivo_correccion. Se declara de forma visible que ni la orden ni la prueba se reabren: la prueba sigue publicada y la corrección ocurre en el ciclo de versiones del resultado.

7.8 Microbiología y derivación

S-33 · Cultivo y lecturas

Cubre: PO-11 · CU-19. Actor: microbiología.

Cabecera con medio, temperatura, siembra, incubación y estado (sembrado / incubando / lectura / finalizado / contaminado / cancelado). Lecturas como línea de tiempo por secuencia, con hora, descripción macroscópica y microscópica, crecimiento y recuento. Una lectura preliminar ofrece emitir informe parcial; el resto de la orden sigue su curso y así se indica.

S-34 · Aislamientos y antibiograma

Cubre: PO-11 · CU-19. Actor: microbiología, validador.

Aislamientos numerados con microorganismo —de catálogo o texto libre, nunca ambos, y el formulario lo impone— cantidad y significancia. Por aislamiento, un antibiograma que exige método, fuente y versión del punto de corte antes de aceptar mediciones. Tabla de antimicrobianos con diámetro, MIC o concentración e interpretación S / I / R / SDD / no_interpretable, con la letra siempre escrita junto al color.

Un recordatorio en la pantalla: lo que deba aparecer en el informe se expresa además como versión de resultado de los analitos de la prueba, porque el informe se compone solo de resultado_version.

S-35 · Derivaciones externas

Cubre: PO-12 · CU-20. Actor: recepción técnica.

Lista por estado (preparada / enviada / recibida_destino / resultado_recibido / cancelada) con laboratorio, número de envío, fechas y días transcurridos. El detalle registra el soporte —muestra o alícuota, exactamente uno—, condiciones de transporte, retorno, informe externo y responsable firmante. El resultado incorporado se rotula visiblemente con su origen laboratorio_referencia y con quién lo firmó: nunca se presenta como producido en casa.

7.9 Inventario

S-36 · Reactivos y lotes

Cubre: PO-13. Actor: almacén.

Reactivos con saldo utilizable, mínimo y déficit desde v_reactivos_stock_bajo; los que están en o bajo mínimo, arriba y en ámbar. Al expandir, lotes con número, vencimiento, estado y saldo. Un lote vencido o bloqueado se muestra atenuado con la razón.

S-37 · Movimiento y consumo

Cubre: PO-13 · CU-21. Actor: almacén, técnico.

Registro de entrada, salida, ajuste, devolución o descarte con cantidad, motivo, documento y saldo resultante visible antes de confirmar — el saldo lo calcula la aplicación, así que mostrarlo es la única forma de que un error se vea.

En el consumo por ejecución, la interfaz deja claro que el consumo no mueve el saldo por sí solo y encadena ambos registros en una sola operación. Al intentar un lote vencido o bloqueado, el rechazo es previo y explica la única salida legítima: cambiar el estado del lote con justificación auditada.

7.10 Configuración, seguridad y auditoría

S-38 · Catálogo de pruebas

Cubre: PO-01. Actor: administración.

Lista con código, nombre, sección, método, TAT y marcas de sensible, requiere_consentimiento y derivacion_externa_predeterminada. Inactivar explica que la prueba deja de ofrecerse para órdenes nuevas sin alterar las registradas.

S-39 · Editor de prueba

Cubre: PO-01. Actor: administración.

Pestañas: Identificación · Analitos · Requisitos de muestra · Equipos habilitados · Reactivos · Códigos externos · Datos clínicos exigidos.

Un analito declara tipo de valor, unidad, decimales, fórmula y orden; los de tipo opción listan sus valores codificados. Antes de activar la prueba, un panel de completitud enumera lo que falta: sin requisito de muestra no se puede tomar, sin analitos no produce resultado.

S-40 · Intervalos de referencia

Cubre: PO-01. Actor: administración, calidad.

Por analito, tabla de intervalos con método, unidad, sexo biológico, rango de edad en días, valores mínimo y máximo, límites críticos y vigencia. Un solapamiento se detecta al editar y se dibuja: dos barras de vigencia superpuestas con el conflicto marcado, porque el modelo lo rechaza al guardar y el usuario debe verlo antes.

La edad se rotula en días con su equivalencia legible. Una nota advierte que la gestación solo cabe en el campo libre poblacion y que, por tanto, una referencia ajustada por embarazo exige selección asistida y evidencia; no se resuelve sola.

S-41 · Reglas clínicas

Cubre: PO-01 · CU-13, CU-14. Actor: administración, calidad.

Tres pestañas: reflejas, delta y autovalidación. Cada regla muestra versión, vigencia, profesional aprobador y estado. El editor de condiciones es un constructor legible, no JSON crudo, con vista previa de la expresión. Antes de publicar, simulación contra resultados históricos que responde cuántos habría disparado: publicar una regla de autovalidación sin esa cifra a la vista es temerario.

Toda regla muestra su historial de ejecuciones con la decisión registrada.

S-42 · Tarifas

Cubre: PO-01. Actor: administración.

Precio por prueba, tipo de precio, aseguradora, plan, moneda y vigencia, con la misma visualización de solapes que S-40.

S-43 · Usuarios y roles

Cubre: PO-15. Actor: administración.

Cuentas con proveedor de identidad, estado y profesional enlazado. La asignación de roles es histórica, con vigencia y sin solapes. La pantalla explica por qué existen dos identidades: cuenta_usuario ejecuta, profesional_laboratorio aprueba y firma. Al enlazar una cuenta con un profesional, se advierte qué acciones clínicas habilita.

S-44 · Auditoría

Cubre: PO-15 · CU-22. Actor: auditoría.

Búsqueda sobre evento_auditoria por entidad, registro, acción, actor, rol efectivo, origen, correlación y rango de fechas. La comparación antes/después se muestra campo a campo. Las consultas a resultados sensibles se auditan también, y la propia pantalla lo indica: quien consulta aquí queda registrado.

S-45 · Alertas

Cubre: PO-15. Actor: todos según destinatario.

v_alertas_activas por tipo, prioridad y antigüedad, con enlace directo al objeto. Una nota fija recuerda que una alerta no sustituye a una notificacion_critica ni a un evento_bloqueo_analitico: cerrarla no cierra el hecho.

8. Cobertura de procesos

Los 24 casos de uso quedan asignados: CU-01 → S-03/S-04 · CU-02 → S-05 · CU-03 → S-07 · CU-04 → S-08 · CU-05 → S-09 · CU-06 → S-10 · CU-07 → S-12 · CU-08 → S-13 · CU-09 → S-15 · CU-10 → S-17 · CU-11 → S-22/S-23 · CU-12 → S-22/S-24 · CU-13 → S-27/S-41 · CU-14 → S-26/S-27 · CU-15 → S-26/S-27 · CU-16 → S-28/S-29 · CU-17 → S-30/S-31 · CU-18 → S-32 · CU-19 → S-33/S-34 · CU-20 → S-35 · CU-21 → S-37 · CU-22 → S-44/S-31 · CU-23 → S-25 · CU-24 → S-20.

9. Flujos entre pantallas

Atención completa: S-03 → S-05 → S-09 → S-10 → S-12 → S-13 → S-15 → S-21 → S-22 → S-26 → S-27 → S-30 → S-31, con S-06 accesible en todo momento como eje.

Muestra rechazada: S-13 (decisión nueva_toma) → nuevo código enlazado → S-12 → S-13 → S-14 muestra ambas cadenas.

Control fallido: S-17 (rechazada) → S-18 con el impacto listado → resolución autorizada → S-16 libera el cruce → S-21 se reanuda.

Valor crítico: S-22 → criticidad clasificada, autovalidación impedida → S-28 → S-29 → confirmada o escalada → S-30.

Prueba refleja: S-27 evalúa y registra → confirmación si la regla la exige → nueva línea refleja visible en S-06 → S-07 resuelve muestra y tarifa.

Corrección publicada: S-24 → S-32 → nueva versión validada en S-27 → informe sustituto en S-30 → S-31 distingue la entrega de una reimpresión.

10. Interacción compartida

Teclado. Todo el flujo operativo es completable sin ratón. / búsqueda global, g + inicial salta de sección, Esc cierra la capa superior, Ctrl+Enter confirma la acción primaria de un formulario. El foco es visible siempre, con anillo de 2 px en acento y 2 px de separación, y nunca queda oculto tras la cabecera adherida ni tras el pie de un diálogo.

Errores de formulario. Resumen enfocable al principio del formulario, con role="alert", que enlaza a cada campo inválido, más el error en línea bajo cada campo unido con aria-describedby. El resumen no sustituye a los errores en línea. La validación no dispara en cada pérdida de foco: al enviar, y después al corregir.

Confirmaciones. Toda acción irreversible nombra el objeto concreto —«Rechazar la muestra MU-00184213 de Mariana Restrepo, orden ORD-2026-00004182»— pide motivo cuando el modelo o el proceso lo exigen y enumera lo que se conserva. El botón de confirmación dice el verbo, no «Aceptar».

Éxito. Confirmación breve y no bloqueante, con enlace al objeto creado. Las operaciones largas usan progreso determinado.

Concurrencia. Si otro usuario modificó el objeto, se avisa antes de sobrescribir y se ofrece ver la diferencia. Especialmente crítico en inventario, donde el saldo lo calcula la aplicación.

Accesibilidad. Contraste mínimo 4.5:1 en texto y 3:1 en límites de control; ningún significado transmitido solo por color; objetivos de 44 × 44 px con 8 px de separación; prefers-reduced-motion respetado; toda tabla con cabeceras asociadas y toda gráfica con su tabla equivalente navegable.

Seguridad de interacción. Cierre de sesión por inactividad con aviso previo y conservación del borrador. Un resultado sensible no se precarga en vistas previas ni en exportaciones de quien no lo puede ver. La sede activa siempre visible en la cabecera: operar en la sede equivocada es un error silencioso y caro.

11. Criterios de aceptación del diseño

1. Toda pantalla que afecte una muestra o un resultado muestra paciente, orden, sede y estado sin desplazarse.
2. Ningún control deshabilitado aparece sin su causa y su camino de resolución adyacentes.
3. Estado clínico, de muestra y financiero nunca comparten indicador visual.
4. Toda validación, notificación e informe se presenta atado a una versión numerada e identificable.
5. Ninguna versión no vigente puede confundirse con la vigente.
6. Rechazar, cancelar, revertir, liberar, corregir, escalar y entregar piden motivo y nombran el objeto.
7. Un valor crítico no se puede publicar sin pasar por comunicación confirmada o escalada.
8. Una prueba sin alícuota vinculada se señala como tal, nunca como celda vacía.
9. Un lote vencido o bloqueado no se puede seleccionar para consumo desde la interfaz.
10. Ninguna información se transmite solo por color; las cinco familias de estado llevan texto.
11. Cada pantalla define carga, vacío, error, sin permiso y bloqueado.
12. Todo el flujo operativo se completa con teclado, con foco visible y nunca obstruido.
13. Ninguna tabla provoca desplazamiento horizontal del cuerpo de la página en 375 px.
14. Un resultado sensible no aparece en búsquedas, contadores ni exportaciones sin autorización.
15. Los contrastes declarados en §2 se verifican con medición, no con estimación.

12. Prohibiciones explícitas para la generación

Reglas para Stitch y para cualquier iteración posterior:

• Sin emojis, en ningún lugar de la interfaz.
• Sin Inter ni ninguna serif. Sin ligaduras en la monoespaciada.
• Sin negro puro #000000.
• Sin neón, brillo exterior, gradientes de marca ni degradados en texto.
• Sin más de un acento. El rojo, el ámbar y el verde son semánticos y no se usan para navegación ni para adornar.
• Sin filas de tres tarjetas iguales. Sin secciones centradas de tipo «hero» fuera de S-01.
• Sin elementos superpuestos: cada uno ocupa su zona.
• Sin movimiento perpetuo, revelados al desplazar, cascadas ni cifras animadas en el espacio operativo.
• Sin cursores personalizados.
• Sin acciones que solo aparezcan en hover.
• Sin discos giratorios como estado de carga: esqueletos con las dimensiones reales.
• Sin «¿Está seguro?» genérico ni botones «Aceptar» en confirmaciones destructivas.
• Sin nombres de relleno tipo «John Doe» ni marcas inventadas tipo «Acme». Los ejemplos usan nombres y códigos verosímiles del dominio.
• Sin cifras redondas falsas en las maquetas: los datos de ejemplo se ven como datos reales de laboratorio.
• Sin lenguaje comercial vacío. Los rótulos nombran la acción clínica exacta.
• Sin imágenes decorativas de archivo en el espacio operativo.

13. Fuentes y procedencia de las decisiones

14. Uso con Stitch

Pasar las secciones 1 a 5 y 12 como contexto de sistema en cada sesión, y generar una pantalla por solicitud usando su bloque de §7 completo. Incluir siempre el identificador (S-nn), el actor, los estados obligatorios de §4 y las prohibiciones de §12.

Los datos de ejemplo deben parecer reales: ORD-2026-00004182, glucosa 126 mg/dL con bandera H, potasio 6.8 mmol/L como critico_alto, lote LT-4471-B con vencimiento 2026-11-30. Nunca cifras redondas ni nombres de relleno.

Lo generado es una propuesta visual. Antes de implementar hay que verificar contra este documento el contraste, el recorrido de teclado, los cinco estados de pantalla y la separación entre estado clínico, de muestra y financiero.