Manual para autores

Para qué sirve este manual

Este manual es para quien quiere publicar una herramienta digital en redGDPS Lab: una calculadora, un algoritmo interactivo, un simulador, un juego serio, una herramienta basada en inteligencia artificial o un recurso docente o asistencial. Explica qué es el Lab y qué no es, cómo proponer una herramienta, cómo rellenar bien su ficha, qué exige cada estado, cómo gestionar versiones y errores, y qué cuidados regulatorios, de privacidad y de marca hay que tener antes de publicar. Al final encontrarás una lista de comprobación y respuestas a las dudas más habituales.

Qué es redGDPS Lab

redGDPS Lab es una sección de www.redgdps.org en la que la Fundación redGDPS publica herramientas digitales que todavía están en evaluación. Cada herramienta tiene una ficha homogénea, recoge la opinión estructurada de profesionales sanitarios y sigue un proceso visible de promoción, revisión y archivo.

El lema del Lab resume su espíritu: pruébalo, cuestiónalo, ayúdanos a mejorarlo.

Qué es

Un escaparate de herramientas en fase Experimental o Beta, con sus límites a la vista.
Un canal ordenado para que los profesionales opinen, informen de errores y hagan revisiones estructuradas.
Un proceso con criterios públicos para decidir qué herramienta pasa a ser Herramienta redGDPS y cuál se archiva.

Qué no es

No es un sello de aprobación. Estar en el Lab significa que la herramienta se está evaluando, no que esté validada.
No es un alojamiento de aplicaciones. El código de cada herramienta vive fuera del gestor de contenidos de la web; la ficha solo enlaza a ella con la dirección «URL para probar». Está previsto un subdominio aislado, lab.redgdps.org, para alojar las aplicaciones.
No es un canal para publicar productos sanitarios sin control. Las herramientas que pueden considerarse software de producto sanitario necesitan una revisión regulatoria previa (lo verás más abajo).
No decide nada de forma automática. Los cambios de estado los decide siempre la comisión del Lab.

Antes de proponer

Antes de enviar una propuesta, comprueba estos tres puntos.

Encaje

La herramienta debe servir a la misión de la Fundación: la diabetes en atención primaria. Pregúntate:

¿Resuelve un problema real de la consulta, la docencia o la investigación en diabetes?
¿A quién va dirigida: profesionales sanitarios, docentes, investigadores o pacientes?
¿Aporta algo que no exista ya en la web de la redGDPS o en otras herramientas de uso común?

Equipo

Toda herramienta necesita un responsable identificado (una persona o un grupo) que responda de ella mientras esté en el Lab: que conteste a las dudas, corrija errores y prepare las nuevas versiones. Si el equipo incluye perfiles técnicos y clínicos, mejor.

Compromiso de mantenimiento

Publicar en el Lab no termina con la publicación. Implica:

revisar los errores que comuniquen los usuarios;
publicar versiones corregidas y documentar cada cambio;
someterse a la revisión periódica;
mantener disponible la dirección donde se prueba la herramienta.

Si no puedes asumir este mantenimiento, es preferible esperar.

Cómo proponer una herramienta

Entra en «Propón una herramienta» (/lab/proponer). Necesitas una cuenta de usuario de la web; si no la tienes, puedes acceder con tu email desde el propio Lab y recibirás un enlace de acceso.

El formulario pide:

Campo	Obligatorio	Qué poner
Nombre de la herramienta	Sí	El nombre con el que se conocerá
Qué hace o qué problema resuelve	Sí	Dos o tres frases claras
A quién va dirigida	No	Profesionales, pacientes, docentes…
Responsable (persona o grupo)	Sí	Quién responderá de ella mientras esté en el Lab
En qué estado está hoy	No	Idea, prototipo, versión usada en consulta…
Qué datos procesa	No	Si se introducen datos de pacientes y si se envían a algún servidor
Base científica	No	Guías, artículos o validaciones en los que se apoya
Quién la mantendrá y cómo	No	Equipo y forma de mantenimiento

Aunque solo algunos campos son obligatorios, cuanto más completa sea la propuesta, antes podrá evaluarse. Los campos de datos, base científica y mantenimiento son los que más pesan en la decisión.

Cada propuesta pasa por estos estados:

Estado	Significado
Nueva	Recibida, pendiente de leer
En revisión	La comisión la está estudiando
Aceptada	Se preparará su ficha en el Lab
Rechazada	No encaja o no cumple los requisitos en este momento

La ficha de la herramienta

Cada herramienta tiene una ficha con la misma estructura. El equipo del Lab la carga en el panel con la información que facilitas. Una ficha bien hecha es la mejor protección para el usuario y para ti.

Campos de la ficha

Campo	Qué debe contener
Nombre	Breve y reconocible
Lema	Una frase que diga para qué sirve
Resumen	Dos o tres líneas para la rejilla del catálogo
Descripción	Qué hace, cómo se usa y qué resultado da
Tipo	Calculadora, algoritmo interactivo, simulador o visualizador, juego serio o caso gamificado, basada en inteligencia artificial, o recurso docente o asistencial
Destinatarios	Profesionales sanitarios, docentes, investigadores, pacientes (uno o varios)
Versión y fecha	La versión publicada y su fecha
Responsables	Personas o grupo que responden de la herramienta
URL para probar	Dirección donde se usa la herramienta
Uso previsto	Para qué y en qué contexto debe usarse
Uso no previsto	Para qué no debe usarse
Datos que procesa y dónde	Qué datos se introducen y dónde se procesan o guardan
Base científica	Fuentes en las que se apoya
Cómo citarla	Referencia recomendada
Última y próxima revisión	Fechas del ciclo de revisión
Historial de versiones	Cambios de cada versión
Motivo de archivo	Solo si se archiva

Uso previsto

Debe decir quién, para qué y en qué contexto.

Bien: «Apoyo docente para que profesionales de atención primaria practiquen la elección del tratamiento farmacológico en la diabetes tipo 2 según el algoritmo de la redGDPS, con casos simulados.»
Mal: «Ayuda a tratar la diabetes.»

Uso no previsto

Debe nombrar los usos indebidos más probables. No basta con un aviso genérico.

Bien: «No sustituye el juicio clínico. No debe usarse para decidir el tratamiento de un paciente concreto. No está validada en diabetes tipo 1, gestación ni población pediátrica.»
Mal: «Úsese con precaución.»

Datos que procesa

Debe decir qué datos se introducen, dónde se procesan y si salen del dispositivo.

Bien: «Se introducen edad, HbA1c, filtrado glomerular y fármacos actuales. Todo el cálculo se hace en el navegador; no se envía ni se guarda ningún dato.»
Mal: «Datos clínicos básicos.»

Base científica

Debe citar fuentes concretas y verificables, y decir si la herramienta se ha validado.

Bien: «Algoritmo de tratamiento de la DM2 de la redGDPS (edición vigente), con las referencias completas. Sin validación externa todavía; se ha comparado con 40 casos clínicos simulados revisados por dos médicos de familia.»
Mal: «Basada en la evidencia más reciente.»

Estados de una herramienta

Estado	Qué significa	Qué requiere
En preparación	Solo se anuncia en la portada; no tiene ficha visible	Propuesta aceptada y equipo trabajando
Experimental	Primera versión abierta a la opinión de los profesionales	Ficha completa, URL para probar operativa, uso previsto y no previsto claros, revisión regulatoria hecha si procede
Beta	Versión madura, en evaluación amplia	Cumplir los criterios orientativos para pasar a Beta y la decisión de la comisión
Herramienta redGDPS	Herramienta oficial de la Fundación	Cumplir los criterios orientativos para la promoción y la decisión de la comisión
Archivada	Ya no se mantiene o no superó la evaluación	Decisión de la comisión con un motivo público

Los cambios de estado los decide siempre la comisión del Lab. El panel solo sugiere una promoción cuando se cumplen los criterios; nunca cambia el estado por sí solo.

Versiones e historial de cambios

Cada vez que publiques una versión nueva, facilita:

el número de versión (por ejemplo, 1.2.0);
la fecha;
una lista breve de los cambios, en lenguaje que entienda un clínico.

Al añadir una versión al historial se actualizan la versión y la fecha de la ficha.

Importante: las opiniones se recogen por versión. Una versión nueva reinicia las opiniones de esa versión: cada profesional puede volver a opinar sobre ella. Por eso conviene agrupar los cambios en versiones con sentido, en lugar de publicar una versión por cada pequeño ajuste.

Ejemplo de entrada en el historial:

1.2.0 (15-01-2027). Corrige el cálculo cuando el filtrado glomerular es inferior a 30. Añade un aviso cuando falta la HbA1c. Mejora la lectura en el móvil.

Errores comunicados por los usuarios

Cuando un usuario comunica un error o un resultado inesperado, entra en el panel como abierto y sin gravedad. El equipo del Lab lo clasifica:

Gravedad	Cuándo	Ejemplo
Crítico	Puede inducir un error clínico	Recomienda un fármaco contraindicado con un filtrado glomerular bajo; un cálculo de dosis da un valor erróneo
Funcional	La herramienta falla o no hace lo que promete, sin riesgo clínico directo	Un botón no responde; un cálculo no se puede completar en un navegador concreto
Cosmético	Aspecto, textos o maquetación	Una errata; un texto que se corta en el móvil

Cada error pasa a resuelto cuando se corrige o a descartado cuando no es un error (por ejemplo, un uso fuera del uso previsto).

Como autor:

Atiende primero los errores críticos. Un error crítico abierto bloquea cualquier promoción.
Reproduce el error con los datos que da el usuario antes de corregirlo.
Publica la corrección como versión nueva y descríbela en el historial.
Si crees que un error es grave y la corrección va a tardar, comunícalo al equipo del Lab: la comisión puede decidir medidas como retirar temporalmente el enlace para probarla.

Revisión periódica

Cada herramienta tiene una fecha de última revisión y una de próxima revisión, visibles en la ficha. Con los valores actuales, la revisión toca cada 6 meses en Experimental y Beta y cada 12 meses en las Herramientas redGDPS.

En la revisión se comprueba, como mínimo, que la base científica sigue vigente, que no hay errores abiertos sin atender y que la ficha refleja la versión real.

Si la revisión vence sin hacerse, el panel lo marca como revisión vencida. La comisión decide entonces qué hacer: pedir la revisión al responsable, mantener la herramienta en su estado o archivarla. Una revisión vencida durante mucho tiempo es un motivo habitual de archivo.

Promoción y archivo

Criterios orientativos de promoción

Estos son los valores actuales; la comisión del Lab puede ajustarlos en los parámetros del panel.

Paso	Criterios actuales
Experimental → Beta	50 profesionales distintos que han opinado; utilidad media ≥ 3,5; ningún error crítico ni sin clasificar abierto
Beta → Herramienta redGDPS	200 profesionales distintos; al menos 3 meses en Beta; utilidad media ≥ 4; ≥ 70 % la usaría; ningún error crítico, funcional ni sin clasificar abierto

Para pasar de Beta a Herramienta redGDPS cuentan también las revisiones estructuradas de los revisores del panel. Con los valores actuales: al menos 5 revisiones, que al menos el 60 % recomiende promocionarla y una media de 4 o más en la dimensión de seguridad. Cada revisor cuenta una vez, con su revisión más reciente. La comisión puede ajustar esas cifras en Lab → Parámetros.

En la ficha pública solo se publica el número de revisiones («N revisiones de expertos»). Las puntuaciones por dimensión, el SUS, los veredictos y los comentarios los ve el equipo del Lab en el panel (ficha de la herramienta y pestaña Revisiones) y se comparten con los autores para preparar versiones nuevas.

Los indicadores públicos de la ficha (revisores, utilidad media y porcentaje que la usaría) solo se muestran cuando han opinado al menos 30 profesionales distintos (valor actual). Cada profesional cuenta una vez, con su opinión más reciente.

Cumplir los criterios no garantiza la promoción: es una condición para que la comisión la estudie.

Archivo

Una herramienta se archiva, por ejemplo, cuando deja de mantenerse, cuando su base científica queda superada o cuando no supera la evaluación. Las herramientas archivadas siguen visibles en /lab/archivo con un aviso y el motivo del archivo, pero sin el botón para probarlas.

Nota regulatoria: software de producto sanitario

Algunas herramientas pueden considerarse software de producto sanitario según el Reglamento (UE) 2017/745 sobre productos sanitarios (MDR), en particular su regla 11. Es el caso típico de herramientas que:

calculan una decisión de tratamiento para un paciente concreto;
hacen predicciones individuales (por ejemplo, la respuesta esperada de un paciente a un fármaco);
orientan un diagnóstico o una decisión terapéutica individual.

Estas herramientas necesitan una revisión regulatoria antes de publicarse en el Lab. Además, la ficha debe dejar muy claro el uso previsto. Por ejemplo, una herramienta predictiva puede publicarse con un uso previsto docente o de investigación, siempre que la revisión regulatoria lo respalde y el uso no previsto excluya expresamente la decisión clínica sobre pacientes concretos.

Si dudas de si tu herramienta entra en este supuesto, indícalo en la propuesta. Es mejor preguntar antes que retirar después.

Privacidad

Prefiere herramientas que mantengan los datos en el dispositivo (cálculo en el navegador, sin envío a servidores).
Nunca envíes datos identificables de pacientes a servidores no auditados. Esto incluye servicios externos de inteligencia artificial, analítica o almacenamiento.
Si la herramienta necesita un servidor, explica en la ficha qué datos recibe, dónde está, cuánto tiempo los guarda y quién responde de él.
Diseña la interfaz para que no pida nombre, número de historia ni otros identificadores si no son imprescindibles.

Licencia y cita

Rellena el campo «Cómo citarla» con una referencia completa: autores, nombre de la herramienta, versión, Fundación redGDPS, año y dirección.

Ejemplo:

Apellido A, Apellido B. Nombre de la herramienta (versión 1.2.0). redGDPS Lab, Fundación redGDPS; 2027. Disponible en: https://www.redgdps.org/lab/nombre-herramienta

Marca

El logotipo de la redGDPS solo se usa según las normas de la Fundación. No lo modifiques ni lo combines con otros logotipos sin autorización.
Mientras la herramienta esté en Experimental o Beta, no la presentes como «Herramienta redGDPS» ni como recomendación oficial de la Fundación.
Indica el estado del Lab en la propia herramienta cuando sea posible, para que quien llegue a ella sin pasar por la ficha conozca sus límites.

Lista de comprobación antes de publicar

Comprobación	Hecho
Hay un responsable identificado y un plan de mantenimiento
La URL para probar funciona en ordenador y en móvil
El uso previsto dice quién, para qué y en qué contexto
El uso no previsto nombra los usos indebidos más probables
La ficha explica qué datos procesa y dónde
No se envían datos identificables de pacientes a servidores no auditados
La base científica cita fuentes concretas y dice si hay validación
Se ha hecho la revisión regulatoria, si la herramienta puede ser producto sanitario
Versión, fecha e historial de cambios están completos
La referencia para citarla está completa
La licencia está indicada
El uso del logotipo respeta las normas de la Fundación

Preguntas frecuentes

¿Tengo que alojar yo la herramienta? Sí, de momento. El código vive fuera del gestor de contenidos de la web y la ficha enlaza a él. Está previsto un subdominio aislado, lab.redgdps.org, para alojar las aplicaciones.

¿Puedo cambiar de estado mi herramienta cuando cumpla los criterios? No. El panel sugiere la promoción, pero el cambio lo decide siempre la comisión del Lab.

¿Se pierden las opiniones al publicar una versión nueva? No se borran, pero las opiniones se recogen por versión: la versión nueva empieza su propia ronda de opiniones.

¿Quién clasifica la gravedad de los errores? El equipo del Lab, desde el panel. Los errores llegan sin gravedad y se clasifican como crítico, funcional o cosmético.

¿Por qué no se ven todavía los indicadores en mi ficha? Porque se muestran a partir de un número mínimo de profesionales distintos (30 con los valores actuales).

¿Los criterios de promoción pueden cambiar? Sí. Las cifras de este manual son los valores actuales y la comisión del Lab puede ajustarlas.

Mi herramienta hace predicciones individuales. ¿Puedo publicarla? Solo tras una revisión regulatoria y con un uso previsto muy claro, normalmente docente o de investigación.

¿Qué pasa si no puedo seguir manteniéndola? Avisa al equipo del Lab. La comisión puede buscar otro responsable o archivarla con un motivo público.

Ver también: Manual para revisores · Cómo funciona el Lab