Revisión periódica de los protocolos

1. Objetivo

Establecer cómo la organización revisa periódicamente sus protocolos, qué hace cuando un protocolo deja de corresponder a la operación real, y cómo se registra esa revisión de modo que sea posible saber, en cualquier momento, qué protocolos están vigentes de verdad y cuáles sólo lo parecen.

2. Alcance

Cubre la programación de la revisión, la revisión propiamente tal, la reverificación de las brechas declaradas, la decisión sobre el estado del protocolo y el registro del resultado.

No cubre:

• la redacción inicial de un protocolo nuevo, que sigue el procedimiento de creación del catálogo;
• el control de los cambios del sistema que disparan revisión → FOR-003, que alimenta a éste;
• la recapacitación derivada de un protocolo modificado → FOR-001;
• la decisión editorial de publicar, que es un acto separado de la revisión;
• la revisión de los documentos clínicos y de los registros de la operación, que se rigen por el bloque de documentos.

3. Definiciones

• Protocolo vigente: el que describe la operación tal como ocurre hoy y ha sido revisado dentro de su plazo.
• Plazo declarado: la frecuencia y la fecha de próxima revisión que el propio protocolo fija.
• Protocolo vencido: aquel cuya fecha de próxima revisión pasó sin que la revisión se ejecutara. Un protocolo vencido no deja de estar publicado por el solo hecho de vencer.
• Revisión ordinaria: la que ocurre por cumplimiento del plazo.
• Revisión extraordinaria: la que dispara un cambio del sistema, un hallazgo o una decisión.
• Brecha declarada: limitación reconocida en la sección de implementación de un protocolo. Su reverificación es parte obligatoria de la revisión.
• Deriva documental: divergencia entre lo que el protocolo describe y lo que la organización hace.

4. Roles y responsables

Rol	Responsabilidad
Dueño de proceso	Es dueño del protocolo. Programa las revisiones y conduce la de cada protocolo de su ámbito.
Calidad	Mantiene el calendario, identifica los vencidos y convoca.
Producto y TI	Informan los cambios del sistema con efecto documental y reverifican las brechas declaradas.
Dirección	Aprueba los cambios de fondo y las decisiones de retiro.
Jefatura	Recibe el resultado y dispara la recapacitación cuando corresponde.

5. Disparador de inicio

Cualquiera de estos cinco:

1. Se cumple la fecha de próxima revisión declarada por el protocolo.
2. Un cambio relevante del sistema altera lo que el protocolo describe (FOR-003, paso 12).
3. Una no conformidad o un hallazgo revela deriva documental.
4. Cambia una obligación normativa que el protocolo cita.
5. Se cierra o se agrava una brecha declarada en la sección de implementación.

6. Requisitos previos

• Existe calendario de revisión con responsable asignado por protocolo.
• Cada protocolo declara su frecuencia y su fecha de próxima revisión.
• Está definido el umbral a partir del cual un cambio del sistema obliga a revisión extraordinaria.
• Están definidos los estados posibles y quién autoriza cada transición.

7. Entradas

• El protocolo en su versión vigente, con su historial de versiones.
• La bitácora de cambios del sistema ocurridos desde la última revisión.
• Los hallazgos, no conformidades y casos que involucraron al proceso descrito.
• El estado actual de las brechas declaradas en la sección de implementación.

8. Procedimiento paso a paso

1. Calidad recorre el catálogo, identifica los protocolos cuya fecha de próxima revisión venció o está por vencer y convoca al dueño de proceso de cada uno.
2. El dueño de proceso reúne las entradas del §7.
3. El dueño de proceso contrasta cada sección del protocolo con la operación real: si el procedimiento se ejecuta como está escrito, si los roles siguen existiendo y si los registros se generan.
4. Producto y TI reverifican cada brecha declarada en la sección de implementación: si sigue abierta, si se cerró, o si se agravó. Una brecha que se cerró y no se actualiza convierte al protocolo en injustamente pesimista; una que se agravó y no se actualiza lo convierte en engañoso.
5. Se verifica que las normas citadas sigan vigentes y que sus cláusulas no hayan cambiado de numeración ni de contenido.
6. Se determina el resultado según el §10: sin cambios, con cambios menores, con cambios de fondo, o retiro.
7. Si hay cambios, el dueño de proceso los redacta, sube la versión y completa el historial de versiones indicando qué cambió y por qué.
8. Los cambios de fondo y los retiros los aprueba Dirección antes de surtir efecto.
9. El dueño de proceso fija la fecha de próxima revisión y la registra en el protocolo.
10. Calidad levanta acta de la revisión, con fecha, participantes, resultado y decisiones.
11. Si el protocolo estaba publicado y cambió su contenido de fondo, la decisión de mantenerlo publicado se toma explícitamente. Un protocolo modificado no queda publicado por inercia.
12. Jefatura evalúa si el cambio obliga a recapacitación según FOR-001.
13. Calidad actualiza el calendario y el registro de vencidos.

Los trece pasos se ejecutan fuera del sistema. Ver §17.

9. Puntos de control

#	Control	Momento	Naturaleza
C1	Identificación de los protocolos vencidos o por vencer	Paso 1	Humano
C2	Contraste con la operación real, no sólo lectura del texto	Paso 3	Humano
C3	Reverificación de cada brecha declarada	Paso 4	Humano
C4	Verificación de la vigencia de las normas citadas	Paso 5	Humano
C5	Historial de versiones completado al cambiar el contenido	Paso 7	Humano
C6	Aprobación de Dirección para cambios de fondo y retiros	Paso 8	Humano
C7	Fecha de próxima revisión fijada y registrada	Paso 9	Humano
C8	Decisión editorial explícita tras un cambio de fondo	Paso 11	Humano
C9	Acta de revisión levantada	Paso 10	Humano
C10	El bloque, el estado y la prioridad sólo admiten valores válidos	Publicación	Automatizado
C11	Doble llave: un protocolo se publica sólo si su estado es vigente y la decisión editorial es afirmativa	Publicación	Automatizado

Nueve de los once controles son humanos. Los dos automatizados —C10 y C11— actúan sobre la publicación, no sobre la revisión: impiden que se publique un protocolo con un valor de estado inválido o sin decisión editorial, pero no tienen ninguna opinión sobre si el protocolo fue revisado alguna vez. C3 es el control que separa una revisión real de una lectura: sin reverificar las brechas, la revisión no toca la parte del documento que más envejece.

10. Criterios de decisión

Situación	Resultado
El protocolo describe la operación real y sus brechas siguen igual	Sin cambios; se registra la revisión y se fija fecha nueva
Erratas, redacción o referencias	Cambios menores; sube la versión menor
El procedimiento cambió, o una brecha se cerró o se agravó	Cambios de fondo; sube la versión y aprueba Dirección
El proceso descrito ya no existe en la organización	Retiro, con constancia del motivo y de la fecha
El protocolo se solapa con otro	Fusión, con constancia de cuál absorbe a cuál
La revisión no puede ejecutarse en plazo	Se registra el vencimiento y se fija fecha comprometida

Un protocolo no se considera revisado por ninguna de estas vías: que se haya leído sin contrastarlo con la operación; que no haya cambiado el texto; que se haya actualizado la fecha sin acta; ni que el sistema no haya cambiado desde la revisión anterior.

11. Excepciones y escalamiento

• Protocolo vencido cuyo dueño de proceso ya no está. Calidad escala a Dirección para reasignar. Mientras no haya dueño, el protocolo se marca como vencido y sin responsable, no como vigente.
• Cambio del sistema que deja obsoleto un protocolo publicado. La corrección de la sección de implementación es prioritaria sobre el resto de la revisión, porque es la parte que se lee como descripción del sistema.
• Brecha declarada que se cerró. Se actualiza en la revisión más próxima; no se espera al plazo ordinario si el protocolo está publicado.
• Norma citada que cambió de numeración. Se corrige la cita. Una cita a una cláusula inexistente desacredita todo el mapeo normativo del documento.
• Vencimiento generalizado del catálogo. Si la proporción de protocolos vencidos supera el umbral definido, se deriva a no conformidad según CAL-006: el problema deja de ser de un protocolo y pasa a ser del ciclo de revisión.

12. Registros generados

• Calendario de revisión con responsable y fecha por protocolo.
• Acta de revisión con fecha, participantes, resultado y decisiones.
• Historial de versiones dentro de cada protocolo.
• Constancia de aprobación de Dirección para cambios de fondo y retiros.
• Registro de protocolos vencidos, con días de vencimiento.
• Constancia de la decisión editorial posterior a un cambio de fondo.

El historial de versiones vive dentro de cada protocolo. El resto es documental y externo al sistema. Ver §17.

13. Indicadores

Indicador	Fórmula	Meta	Fuente
Revisión en plazo	Protocolos revisados dentro de su plazo ÷ protocolos con plazo vencido en el período	100 %	Calendario y actas
Vencimiento acumulado	Suma de días de vencimiento de los protocolos vencidos	Tendencia a cero	Calendario
Revisión por cambio del sistema	Cambios relevantes con revisión documental ÷ cambios relevantes	100 %	FOR-003 y actas
Brechas reverificadas	Protocolos con brechas reverificadas ÷ protocolos revisados	100 %	Actas
Protocolos publicados y vencidos	Publicados con plazo vencido ÷ publicados	0	Calendario y catálogo

El último indicador es el más importante del protocolo y debe valer cero: un protocolo publicado y vencido es exactamente el riesgo principal, visible desde fuera de la organización. El cuarto es el que distingue una revisión de una lectura.

14. Riesgos y controles

Riesgo	Control	Tipo
Catálogo que envejece sin que nadie lo advierta	C1 y el calendario. Sin aviso automático: ver brecha 1	Detectivo
Revisión que sólo lee el texto	C2, C3	Preventivo
Sección de implementación desactualizada	C3	Preventivo
Cita normativa a una cláusula inexistente	C4 y la regla del §11	Detectivo
Cambio sin rastro en el historial de versiones	C5. Sin verificación automática: ver brecha 3	Detectivo
Protocolo modificado que queda publicado por inercia	C8, C11	Preventivo
Protocolo sin fecha de próxima revisión	C7. El campo es opcional: ver brecha 2	Preventivo
Pérdida de la versión anterior de un documento	Ver brecha 4 de la §17	—

15. Normativa y referencias

Norma	Cláusula	Qué paso la cubre
ISO 9001:2015	§7.5.3, control de la información documentada	Pasos 3 a 11: revisión, aprobación, versionado y control de obsoletos
ISO 9001:2015	§9.3, revisión por la dirección	Pasos 8 y 11, cuando el resultado exige decisión de Dirección
ISO 9001:2015	§10.3, mejora continua	Pasos 6, 7 y 12: la revisión produce cambio y capacitación, no sólo constancia
Ley 20.500	Órganos de la asociación	Paso 8: quién aprueba dentro de la estructura de la organización

Precisiones que acotan estas citas:

• Cobertura no es cumplimiento. Que un paso mapee a §7.5.3 no significa que la organización cumpla §7.5.3 ni que esté certificada.
• Los dos controles automatizados operan sobre la publicación. No verifican que una revisión haya ocurrido, y presentarlos como control de vigencia documental sería inexacto.
• Nada de este protocolo constituye asesoría legal ni certificación de una autoridad.

Protocolos relacionados: [[wiki/entities/dispensai/protocolos/FOR-003]], [[wiki/entities/dispensai/protocolos/FOR-001]], [[wiki/entities/dispensai/protocolos/FOR-005]], [[wiki/entities/dispensai/protocolos/CAL-006]], [[wiki/entities/dispensai/protocolos/DOC-001]].

16. Anexos y formularios vinculados

• Calendario de revisión del catálogo.
• Formato de acta de revisión.
• Pauta de contraste entre protocolo y operación real.
• Pauta de reverificación de brechas declaradas.
• Matriz de estados y de autorizaciones de transición.

17. Implementación en el sistema

Este protocolo no está implementado en el sistema. El catálogo declara sus plazos de revisión y el sitio los muestra, pero nada los vigila. Lo que el sistema sí controla es la forma y la publicación de la ficha, no su vigencia.

Elemento del protocolo	Dónde vive
Frecuencia y fecha de próxima revisión	Encabezado de cada protocolo en el vault
Presentación de la fecha de próxima revisión	Ficha pública del protocolo, como metadato
Validación de bloque, estado y prioridad	Esquema del catálogo: son enumeraciones cerradas y un valor inválido detiene la construcción del sitio
Doble llave de publicación	Filtro del sitio: se publica sólo con estado vigente y decisión editorial afirmativa
Historial de versiones	Tabla dentro del propio protocolo
Pasos 1 a 13	Fuera del sistema. Registro documental de la organización

Brechas conocidas:

1. Nada vigila la fecha de próxima revisión. Se verificó el 2026-08-29 sobre el código del sitio: el único lugar que consume esa fecha la imprime como metadato en la ficha del protocolo. No hay comparación contra la fecha actual, no hay listado de vencidos, no hay aviso y no hay fallo de construcción. Consecuencia: un protocolo puede vencer y seguir publicado indefinidamente, con su fecha de revisión vencida a la vista de cualquiera que abra la ficha. Es la brecha mayor del protocolo y la razón por la que el control C1 es enteramente humano.

2. La fecha de próxima revisión es opcional. El esquema del catálogo la declara como campo opcional, mientras que el bloque, el estado y la prioridad son enumeraciones cerradas que detienen la construcción ante un valor inválido. Consecuencia: un protocolo sin fecha de revisión se construye y se publica igual, y queda fuera de cualquier calendario que se arme leyendo el catálogo. El campo que sostiene todo este protocolo es el menos exigido del encabezado.

3. Nada verifica que el historial de versiones se actualice. El historial es una tabla dentro del documento. Un cambio de contenido sin fila nueva en esa tabla se publica sin objeción. El control C5 depende por completo de la disciplina de quien edita.

4. El único control de versiones automático del sistema pierde la versión anterior en silencio. Existe en la aplicación un módulo de reglamento interno que sí guarda una instantánea de la versión previa antes de sobrescribir el documento. Pero si esa instantánea falla, el error sólo se imprime en la consola del servidor y la sobrescritura continúa: el documento queda actualizado y su versión anterior desaparece sin aviso. Además, ese módulo opera sobre tablas que el repositorio no crea —ver la brecha 3 de FOR-003—, de modo que no es reproducible en una organización nueva. Se cita como precedente porque es el mecanismo más cercano a lo que este protocolo describe, y muestra la forma exacta del defecto a evitar.

5. La revisión no deja rastro dentro del sistema. No hay acta, no hay calendario, no hay registro de vencidos y no hay constancia de la decisión editorial. Todo el ciclo es documental.

Lo que esto significa en la práctica. La organización puede conducir legítimamente la revisión periódica con calendario y actas documentales. Lo que no puede afirmarse es que el catálogo se autovigile: la fecha de próxima revisión que muestra cada ficha es una declaración de intención, no un control, y quien la lea desde fuera de la organización no debe interpretarla como garantía de que la revisión ocurrió. Mientras las brechas 1 y 2 sigan abiertas, la única forma de saber qué protocolos están vencidos es revisar el calendario documental.

Brecha observada en auditoría 2026-08-31

• Ruta no encontrada exacta: /{codigo} — puede ser variante (singular/plural, /admin vs /dashboard) o ruta renombrada. Acción correctora: actualizar el frontmatter con la ruta real que usa el sistema.

18. Historial de versiones

Versión	Fecha	Cambio	Autor
1.0	2026-08-29	Versión inicial, levantada con el harness de protocolos sobre el sistema real	Dueño de proceso
1.0+audit-2026-08-31	2026-08-31	Detectados gaps en auditoría: /{codigo}. §17 actualizada para documentar la brecha con evidencia de código. Estado documental sin cambio.	Auditoría automática