ESTADO DEL PROTOTIPO
Qué demuestra PharmacOps y qué queda por validar.
Esta página separa el alcance del prototipo, las funciones conectadas y la evolución prevista. El estado publicado corresponde a esta primera versión del prototipo.
| Capacidad | Estado | Evidencia | Límite |
|---|---|---|---|
| Landing y contenido | Disponible | Páginas renderizadas en esta versión | Describe una propuesta y su estado; no un despliegue hospitalario |
| Gemelo poblado de la landing | Fixture preparado | T01 de 5 × 4 con 16/20 posiciones y reglas de ejemplo | No es inventario real ni se sincroniza con /demo |
| Identificación de ejemplos | Probado en demostración | Cuatro resultados preparados en /demo | No analiza imágenes nuevas ni mide precisión |
| Destinos y reservas | Probado en demostración | Motor local y tests de invariantes | Estado aislado en memoria del navegador |
| Confirmación y vaciado | Probado en demostración | Acciones explícitas y eventos de sesión | Declaración humana; sin sensor físico |
| Revisión individualizada | Probado en demostración | T02-R1–R4 o posiciones de T01 | No representa una cola hospitalaria real |
| Captura móvil conectada | Pendiente | /captura informa que no está disponible | Sin emparejamiento ni autorización de servidor |
| Análisis de imagen nueva | Pendiente | /estacion informa que no está conectado | Sin proveedor, muestras de prueba ni catálogo autorizado |
| Automatización física | Evolución prevista | Diagrama conceptual de fase 2 | Sin robot ni verificación física |
| Validación clínica | Pendiente | Sin resultados publicados | No determina aptitud para dispensación |
Qué mediremos
El impacto se demuestra con datos, no con porcentajes decorativos.
- Identificación
- Muestras etiquetadas y versiones de catálogo/modelo
- Revisión
- Casos no resueltos e intervenciones registradas
- Tiempo por fase
- Marcas temporales de sesión y confirmación
- Ubicación
- Contraste entre destino y verificación física
Evidencias visibles. Distinguir lo observado, lo aportado por catálogo y lo confirmado por una persona.
Revisión explícita. No forzar una identidad con información insuficiente.
Acciones trazables. Registrar confirmaciones y correcciones sin borrar el evento anterior.
Alcance declarado. Separar prototipo, ejemplo, integración real y evolución futura.
De dónde salen los datos
La landing muestra un fixture fijo de T01 con 20 celdas y 16 ocupadas. Las denominaciones genéricas y concentraciones elegidas se contrastaron con CIMA de la AEMPS. Los códigos, puntuaciones, zonas, destinos y cantidades son ficticios. En cambio, /demo ofrece cuatro casos sintéticos A–D con resultados de identificación preparados; sus reservas y confirmaciones se calculan localmente durante la sesión. Son ejemplos separados. No hay catálogo hospitalario conectado ni muestras autorizadas cargadas.
Qué hace la persona
En el MVP previsto, el operador presenta una muestra, revisa las evidencias, coloca físicamente la pieza y confirma su ubicación. La demo simula esa declaración mediante el botón de confirmación. La ubicación registrada no equivale a liberación de stock.
Tratamiento de imágenes
Esta versión no permite subir ni capturar imágenes nuevas. No hay servidor o proveedor de procesamiento de imágenes configurado; tampoco están definidos conservación, borrado y acceso para una sesión conectada. La captura seguirá deshabilitada hasta resolver esos puntos y la documentación de privacidad.
Validación pendiente
No hay métricas de precisión ni resultados clínicos. Para evaluarlos se necesitan muestras autorizadas, etiquetas verificadas, versiones de catálogo y modelo, condiciones de ensayo y revisión profesional. El reto de LabORA es el origen del problema, no una acreditación del producto.