Un caso real de certificación SREP contado de forma anónima. Se han omitido nombres de organizaciones, personas, prestadores y sistemas; los mecanismos técnicos y los criterios de auditoría son reales.
Cuando se habla de receta electrónica privada, la atención suele irse a lo visible: el médico que prescribe, la farmacia que dispensa. Pero lo que decide si un sistema pasa o no su auditoría de certificación está en tres capas mucho menos vistosas: cómo entra el sistema en el ecosistema (el onboarding), cómo se cierra criptográficamente cada receta (la firma) y cómo se protege la información una vez almacenada (la confidencialidad). Este es el relato de cómo un grupo hospitalario privado resolvió las tres, y por qué el enfoque que eligió es replicable.
Pieza 1 — El onboarding: no operas si no estás dado de alta, activo y sincronizado
En el Sistema de Receta Electrónica Privada (SREP), ningún repositorio de prescripciones habla directamente con las farmacias. Toda la interoperabilidad pasa por un nodo farmacéutico nacional que actúa como punto único de control. Y ese nodo no deja entrar a cualquiera: mantiene un registro de los repositorios certificados y gestiona su ciclo de vida técnico.
El onboarding del repositorio se articuló en cuatro elementos que el auditor puede verificar uno a uno:
- Identificación única del repositorio dentro del nodo.
- Declaración explícita de la versión funcional que se pone en producción.
- Registro de los endpoints autorizados —solo esas URLs pueden operar.
- Asociación de los certificados de firma y cifrado al repositorio.
A partir de ahí, la regla es tajante: solo los repositorios dados de alta, activos y sincronizados pueden intercambiar información. Una versión no declarada se considera no autorizada y sus operaciones se bloquean; una versión retirada queda desactivada aunque siga registrada en el histórico. El versionado no es un detalle administrativo, es un control de seguridad: impide que software no homologado o versiones antiguas se cuelen en el flujo de dispensación.
La frontera técnica de ese onboarding es un certificado punto a punto emitido por el propio nodo farmacéutico. La interfaz expuesta del repositorio valida ese certificado —por su huella digital— en cada conexión, de modo que la comunicación no pueda proceder de ningún otro origen. No hay «confianza por defecto»: hay verificación en cada llamada.
El resultado es un ecosistema donde entrar cuesta —hay que acreditarse, declararse y sincronizarse— pero donde, una vez dentro, la pertenencia es demostrable y revocable. Exactamente lo que un auditor quiere ver.
Pieza 2 — La firma: un sello central del prestatario, no una firma personal del médico
Aquí está probablemente la decisión de diseño más interesante del proyecto, y la que más preguntas genera cuando se explica.
El sistema no pide al médico que firme criptográficamente cada receta con un certificado personal. En su lugar, cuando el profesional pulsa «Firmar y generar receta», el backend genera el XML completo de la receta y lo firma con un sello electrónico avanzado central, basado en un certificado cualificado de representante de persona jurídica del prestatario del servicio, emitido por un prestador cualificado de servicios de confianza.
¿Por qué es válido esto para el control de formalización documental (FD02)? Porque el marco de certificación no exige un dispositivo cualificado de creación de firma (QSCD) ni que el certificado pertenezca al prescriptor. Lo que exige es que la identidad del prescriptor quede inequívocamente vinculada al acto de prescripción. Y eso se consigue incluyendo dentro del propio XML que se firma los datos que identifican al profesional y su sesión: identificador de usuario, nombre y apellidos, número de colegiado, identificador de conexión, puesto, IP y marca temporal. Todos esos campos forman parte del contenido sellado. Cualquier alteración posterior invalidaría la firma.
El formato elegido es XAdES-LT (XAdES Baseline LT según ETSI EN 319 132), que incorpora todo lo necesario para una validación a largo plazo sin depender de servicios externos:
- Certificado del firmante y su cadena de certificación.
- Evidencias de revocación embebidas (OCSP/CRL).
- Sello de tiempo de una autoridad de sellado.
- Hash SHA-256 del XML completo.
Tres garantías salen de aquí de forma limpia. Autenticidad del emisor, por el certificado cualificado de persona jurídica. Integridad, por el hash del documento completo. No repudio, por la combinación de sello de tiempo, evidencias de revocación y la vinculación del prescriptor en el contenido firmado.
Dos detalles que redondean el modelo, y que el auditor agradece:
- La firma se ejecuta íntegramente en el backend. La clave privada del sello nunca se expone a los usuarios; solo se utiliza a través de una API interna. La autenticación del profesional cumple nivel MEDIO del Esquema Nacional de Seguridad; el entorno de custodia de la clave, nivel ALTO.
- Si la firma falla —caída de conexión, autoridad de sellado no disponible, certificado no accesible—, no se genera ningún documento parcialmente firmado: la prescripción no avanza, se informa al usuario y se registra el incidente. No hay estados a medias.
Como evidencia, el XML firmado se validó contra el validador oficial de firma de la Comisión Europea, con resultado 1 firma válida de 1. Elegir un formato estándar y verificable por terceros convierte una afirmación («está bien firmado») en un hecho comprobable.
Pieza 3 — PD02: la confidencialidad de lo que ya está guardado
Las dos piezas anteriores protegen la entrada y la emisión. La tercera protege lo que queda: las recetas y sus datos de salud almacenados en el repositorio. Es el control PD02 —medidas de seguridad derivadas de la confidencialidad de la información almacenada— y aquí el proyecto no improvisó: se apoyó en una certificación ENS de Nivel Alto ya existente y en una Política de Seguridad de la Información formalmente aprobada.
Ese plan de seguridad no es un documento decorativo; es la estructura que da sentido a todo lo demás. Define roles y responsabilidades (comité de seguridad, responsable de seguridad de la información, responsable del sistema, del servicio, de la información), obliga a una gestión de riesgos con aceptación explícita del riesgo residual, y establece procesos de gestión de incidentes, formación y concienciación. Sobre esa base, PD02 se acredita con medidas concretas en cuatro frentes:
- Acceso físico. Control estricto a instalaciones críticas (CPD, salas técnicas) mediante tarjeta personal, videovigilancia y registro de entradas y salidas, con evidencias auditables.
- Acceso lógico. Autenticación robusta con multifactor cuando procede, gestión centralizada de identidades, principio de mínimo privilegio y separación de funciones, control de sesiones, bloqueo automático y revisiones periódicas de permisos.
- Gestión de soportes. Soportes inventariados, cifrados y gestionados durante todo su ciclo de vida, con destrucción segura al final.
- Registro de accesos. Trazas de acceso a sistemas y datos —usuario, fecha, hora y acción—, con los logs protegidos frente a alteración y revisados de forma periódica.
A esto se suma que el acceso a los datos de receta nunca es directo contra la base de datos: todo pasa por APIs sobre HTTPS/TLS protegidas, y la inmutabilidad de cada receta se garantiza con un hash calculado en el instante de la grabación. Confidencialidad, integridad y trazabilidad, las tres dimensiones que PD02 quiere ver, quedan cubiertas por medidas que ya estaban auditadas de forma independiente en el marco del ENS.
La lección de fondo
Las tres piezas cuentan la misma historia desde ángulos distintos: la seguridad de una receta electrónica privada no se demuestra con una funcionalidad, sino con fronteras bien definidas.
- La frontera de entrada se controla con el onboarding: alta declarada, versión activa, endpoints registrados y certificado punto a punto validado en cada conexión.
- La frontera de emisión se cierra con un sello central del prestatario en formato XAdES-LT, que vincula al prescriptor sin exponer claves ni depender de firmas personales.
- La frontera de custodia se protege con el control PD02 apoyado en un ENS de Nivel Alto y una política de seguridad viva.
Ninguna de las tres es tecnología espectacular. Las tres son decisiones de arquitectura tomadas pensando en que alguien, algún día, tendría que verificarlas. Y esa es, al final, la diferencia entre un sistema que «funciona» y uno que se certifica.
Si dispone de un software a homologar, validar o certificar con mecanismos de firma, sello, encriptación, onboarding, etc podemos ayudarle a minimizar sus riesgos o certificar si cumplimenta nuestro formulario.
