Los cuatro manuales, en una sola lectura
La NCCHC acredita instalaciones, no software. Un estándar sin cobertura no significa que el centro incumpla: significa que el EHR no aporta la evidencia que revisará el encuestador. Por eso el porcentaje se calcula solo sobre los estándares con componente documental.
Siete estándares cubiertos, dos piezas de producto
Todo lo que el sistema cubre por completo se apoya en el módulo de solicitudes de servicios de salud (HSR) y en las escalas de abstinencia CIWA-Ar y COWS. Son dos apuestas deliberadas del equipo que dan justo en el dominio correccional.
Trece brechas explican los 62 estándares sin cobertura
Ninguna es exclusiva de un manual: todas aparecen en los cuatro. La barra mide cuántos estándares quedan bloqueados por cada una, sumando los cuatro manuales.
Cada rúbrica, estándar por estándar
Desglose por sección, hallazgos propios de cada manual y el listado completo, filtrable por estado. Los códigos y títulos son los oficiales del manual correspondiente.
Qué ya está resuelto en LPAS
LPAS 988 es un producto distinto —atiende la línea de crisis— construido con las mismas herramientas que el EHR. Por eso aquí sí tiene sentido rasgar código y traérselo: no se duplica nada, porque son dos productos separados. Con PhyMar no pasa lo mismo, y por eso tiene su propia sección más abajo. Doce cosas que LPAS ya tiene sirven para tareas de este backlog. Aquí se explica qué hace cada una, para qué sirve aquí, qué se aprovecha y qué hay que construir igual.
PhyMar: qué le toca a cada sistema
PhyMar no es un sistema de fuera al que se le copian ideas: es parte de phycore, como este EHR. Eso cambia la pregunta. Con LPAS se trata de qué se puede traer; aquí se trata de quién es el dueño de cada cosa, porque construir dos veces lo mismo dentro de la misma casa no es reutilizar, es duplicar.
La conexión ya existe por un lado: el EHR expone get-phymar-patients y get-phymar-prescriptions —con el comentario // PhyMar added en el código—, y PhyMar los consume buscando al paciente por su mrun. Falta el camino de vuelta.
Lo que PhyMar ya cubre
Ocho cosas que los manuales exigen y que en phycore ya están resueltas — en PhyMar, no aquí. No son tareas de nadie: son huecos del análisis que en realidad no lo son, siempre que el encuestador pueda verlos desde el expediente.
| Lo que ya hace | Qué exigencia cubre | Dónde vive |
|---|---|---|
| Inventario con lotes, vencimiento, saldos y reórdenes | Operaciones farmacéuticas — Essential en los cuatro manuales, y el EHR no tiene nada | src/inventory/ |
| El MAR: una fila por dosis, con estado, quién la marcó y cuándo | Registro de administración de medicamentos | src/administrations/ |
| Cadena de custodia en cajas, con firma al entregar y al recibir | Plan de control de desvío que exige el manual de opioides | src/dispense/ |
| Devoluciones con motivo, y regla de si repone al inventario o no | Desecho y medicación devuelta | src/returns/ |
| Etiqueta con código de barras único por dosis dispensada | Trazabilidad de la dosis; media verificación de identidad | label_barcode_value |
| Horarios de dosis por receta y plantillas por medicamento | Programación de la administración | src/prescriptions/ |
La integración con este EHR, de ida: pacientes y recetas por mrun |
Continuidad entre prescripción y dispensación | src/ehr/ |
| Permisos guardados en base de datos y editables por rol | Control de acceso; el EHR reparte con tres perfiles planos | @RequirePermission |
El backlog de PhyMar
Siete tareas que se desarrollan en PhyMar, con el mismo criterio de criticidad que el backlog del EHR. Cada una dice con qué tarea del EHR hace pareja: casi ninguna sirve sola.
Treinta y cinco tareas, con su impacto medido
Cada tarea nombra los estándares que toca. El impacto no está estimado a ojo: se calcula sobre los 229 estándares evaluados. Toque una tarea para ver dónde se implementa. Criterios de aceptación y detalle técnico completo en analisis/05-backlog.md.
Este backlog es del EHR. Las siete tareas de farmacia viven en el backlog de PhyMar, más arriba; las tareas que necesitan las dos mitades lo llevan escrito en su etiqueta.
El orden de la lista es el orden de desarrollo, y lo manda la criticidad. Crítico aquí significa dos cosas concretas: que se usa todos los días en el centro, o que bloquea a otras tareas del backlog. No es lo mismo que pesar mucho en la acreditación: hay tareas que mueven muchos estándares y casi nadie toca.
Dentro de un mismo nivel el desempate sigue siendo la prioridad por manual que fijó el equipo — Prisiones, Salud mental, Opioides, Juvenil — y después los estándares en rojo, los Essential y el esfuerzo. El número a la izquierda de cada tarjeta es su posición.
La dependencia sigue mandando por encima de todo. Una tarea puede ser C1 y aun así necesitar algo que todavía no existe: no se construye el aviso de plazos antes que el motor de plazos. Por eso cada tarjeta conserva su línea de dependencias.
Lo que cambia respecto al orden anterior. Ordenar por estándares en rojo hundía a las tareas que sostienen al resto. Con este criterio suben: T-05 el motor de plazos, que necesitan otras ocho tareas; T-30 los roles, que habilitan seis; y T-24 reactivar derivaciones, que está construido y apagado. Y baja lo que pesa en la acreditación pero se toca poco.