Receta electrónica privada: pasos para su integración

En España, una receta privada electrónica no es un módulo que se activa desde un panel de ajustes: es una cadena de interoperabilidad regulada cuyos eslabones —el CGCOM, el CGCOF y la plataforma NodoFarma— dependen de los propios colegios profesionales. Si falla cualquiera de ellos, lo que tienes no es una receta electrónica privada válida; es un documento con un logotipo.

Por eso encaro este asunto como acostumbro a encarar cualquier tecnología regulada: con los papeles encima de la mesa y la voluntad de formular preguntas incómodas. La integración de la receta electrónica privada en un software clínico exige coordinar homologación, identidad profesional, firma electrónica, comunicación con NodoFarma, trazabilidad y documentación para el paciente. No basta con que el programa genere un PDF o muestre un código QR.

El marco normativo que conviene leer antes de licenciar nada

El sistema entero descansa sobre un armazón normativo relativamente corto que merece la pena leer con calma antes de cualquier conversación comercial. La cuestión no es convertirse en jurista, sino saber qué parte del discurso del proveedor está respaldada por el procedimiento oficial y cuál es simplemente una promesa de ventas.

El Real Decreto 1718/2010 y la puerta del artículo 14.4

El soporte regulatorio básico del Sistema de Receta Electrónica Privada (SREP) se ampara en el artículo 14.4 del Real Decreto 1718/2010, de 17 de diciembre, sobre receta médica y órdenes de dispensación. Esa disposición, a menudo omitida en los dossiers comerciales, es la que permite la existencia de la receta electrónica en el ámbito privado y condiciona su validez a requisitos técnicos y organizativos fijados por los colegios profesionales.

No es un estándar aspiracional ni una recomendación de buenas prácticas. Es una norma estatal que define quién puede prescribir, qué debe contener la receta y cómo debe poder verificarse. Si la cadena de software no garantiza esos elementos, el resultado puede parecer una receta desde el punto de vista visual, pero no cumple la misma función desde el punto de vista jurídico y operativo.

La distinción es importante para una clínica. Un documento imprimible puede servir como apoyo informativo, pero no sustituye a una receta integrada en un sistema que permita identificar al prescriptor, comprobar su habilitación, aplicar una firma electrónica válida, consultar el estado de la prescripción y facilitar la dispensación en la farmacia.

El convenio de diciembre de 2019 y la cuádruple gobernanza

El 19 de diciembre de 2019, los Consejos Generales de Médicos (CGCOM), Farmacéuticos (CGCOF), Odontólogos y Podólogos firmaron el convenio de colaboración que estableció las bases, el funcionamiento y la gobernanza del SREP. Conviene retener un detalle: son cuatro organizaciones profesionales, no dos.

La integración tiene que satisfacer las exigencias de todos los actores que intervienen en la prescripción y la dispensación, no solo las del colegio de médicos, que es el que la mayoría de fabricantes de sistemas de información hospitalaria conoce mejor. El convenio articuló NodoFarma como el nodo técnico que conecta a los prescriptores con las oficinas de farmacia dispensadoras.

Una imagen mental útil: NodoFarma se parece más al notario de la transacción que a un buzón de intercambio de archivos. Valida identidades, registra eventos de dispensación y vincula la receta con un profesional verificado. Si se confunde ese papel, el diseño técnico se orienta a enviar ficheros cuando, en realidad, debe autenticar actores, controlar estados y conservar evidencias.

La receta electrónica privada no es una funcionalidad aislada de software: es un sistema interoperable con identidad profesional verificada por los colegios.

Homologación ante el CGCOM: el expediente que abre la puerta

Una vez entendido el marco, el procedimiento de homologación deja de ser opaco. Es, además, la fase en la que muchos productos «listos para receta privada» empiezan a desinflarse. La diferencia entre una integración real y una apariencia de integración suele estar en la documentación que el proveedor puede presentar y en la trazabilidad de las pruebas que ha superado.

Solicitud de certificación y apertura del expediente

El primer paso del procedimiento es presentar una solicitud de certificación ante el CGCOM para abrir el expediente de homologación. Esa solicitud inicia un procedimiento administrativo, no un ticket de soporte técnico. La documentación debe permitir entender qué hace el módulo de prescripción, cómo está construida su arquitectura de seguridad, qué flujos de datos utiliza y quién responde por el desarrollo y el mantenimiento.

Hasta que el expediente se abre y se dispone del número correspondiente, no tiene sentido presentar la integración como terminada. El número de expediente es la referencia que permite continuar con las fases técnicas posteriores. Un proveedor que prometa una conexión completa con NodoFarma sin explicar cuál es el estado de su expediente está mezclando dos conceptos distintos: disponer de una interfaz y estar en condiciones de operar dentro del sistema regulado.

La clínica que contrata el servicio también debe pedir una explicación clara sobre el alcance de la homologación. No es lo mismo que esté homologado el producto del fabricante, que lo esté una versión concreta del módulo o que la certificación cubra únicamente determinados flujos de prescripción. La respuesta debería especificar qué se ha validado, con qué versión y bajo qué condiciones de despliegue.

Auditoría previa y documentación técnica

Antes de las pruebas frente a NodoFarma, la entidad desarrolladora suele tener que superar una auditoría previa, frecuentemente realizada por una entidad independiente. No conviene convertir esta fase en una cuestión de precio. Las tasas que cobran estas entidades no forman parte del marco público y pueden variar según el alcance del módulo y la complejidad del despliegue.

Si alguien ofrece un presupuesto cerrado sin haber revisado antes el código, la arquitectura y los flujos de información, la oferta merece una segunda lectura. La auditoría no se limita a comprobar si la pantalla de prescripción funciona. Examina si el comportamiento del sistema coincide con lo que describen sus especificaciones y si existe evidencia suficiente para reconstruir lo sucedido cuando se genera, modifica, anula o dispensa una receta.

Desde el lado de la clínica o del proveedor, conviene preparar al menos:

• La descripción del flujo completo de prescripción, desde la identificación del profesional hasta la emisión de la hoja para el paciente.
• La arquitectura de seguridad y los mecanismos utilizados para proteger las comunicaciones y los datos almacenados.
• La política de gestión de certificados, claves y permisos de usuario.
• La relación de eventos que quedan registrados y el modo de consultar esos registros.
• La trazabilidad de las anulaciones, reintentos, errores de comunicación y cambios de estado.
• El procedimiento de respuesta ante incidentes de seguridad o indisponibilidad del servicio.

Lo que el auditor busca no son cuadros de mando bonitos. Busca pruebas de que el sistema se comporta como está documentado y de que la organización sabe qué hacer cuando una operación no termina correctamente.

Integración técnica con NodoFarma: donde se demuestra el sistema

Con el expediente de homologación abierto llega la parte técnica: la integración con NodoFarma a través del portal de pruebas del CGCOF. Esta fase no consiste en conectar una dirección de internet y comprobar que el servidor responde. Consiste en demostrar que el software interpreta correctamente los estados, las identidades y las reglas del sistema.

Registro en el portal de pruebas del CGCOF

El desarrollador debe registrarse en el portal de pruebas del CGCOF utilizando el número de expediente asignado por el CGCOM. Ese número funciona como referencia de acceso a los entornos de integración. Sin él, no hay una vía ordinaria para avanzar en las pruebas técnicas.

Esto significa que homologación e integración son fases relacionadas y secuenciales, no tareas completamente independientes que puedan improvisarse en paralelo. Un error frecuente de los equipos que intentan acortar plazos consiste en empezar el trabajo técnico sin haber resuelto la parte administrativa, para descubrir después que las credenciales, los accesos o la documentación que necesitan dependen precisamente del expediente.

El portal expone servicios web que simulan el flujo de producción: creación de recetas, consulta para dispensación, anulaciones y consulta del estado de la receta. Cada uno de estos flujos está documentado en las especificaciones técnicas de NodoFarma y el software tiene que gestionarlos de forma determinista.

Eso implica que una respuesta incompleta, un corte de comunicación o una repetición de la solicitud no pueden dejar al sistema en un estado ambiguo. El programa debe distinguir entre una receta creada, una receta pendiente de confirmación, una receta anulada y una operación que ha fallado sin que exista certeza sobre el resultado. Si el equipo de desarrollo piensa que ya verá cómo se comporta el sistema en producción, ha fracasado antes de empezar.

Comprobación automática de la habilitación profesional

El software de prescripción debe superar pruebas técnicas de comprobación automática de la habilitación del profesional colegiado, conectándose con los servicios web de los consejos generales de los profesionales prescriptores. Esta comprobación constituye uno de los núcleos de la validez de la receta: en el momento de la firma, el sistema confirma que el número de colegiado corresponde a un profesional activo, con habilitación en vigor y autorizado para prescribir el tipo de producto correspondiente.

La verificación no debería entenderse como una consulta puntual que se realiza una sola vez al dar de alta al usuario. El sistema debe integrarla en el flujo de emisión y dejar constancia del resultado. También debe gestionar los casos en los que el servicio de comprobación no está disponible, la respuesta es inconsistente o los datos del profesional no coinciden con los registrados en el software clínico.

Lo que el sistema no puede hacer es permitir que una incidencia de verificación se resuelva sustituyéndola por una validación manual sin rastro o por una autorización genérica de administrador. La receta electrónica privada necesita vincular la prescripción con un profesional identificado y habilitado. Si el sistema no puede comprobarlo, debe impedir la emisión o dejar la operación en un estado controlado, según el procedimiento aplicable.

La verificación también debe estar separada de los permisos internos del programa. Que un usuario tenga acceso a la pantalla de prescripción no significa que esté habilitado para emitir cualquier tipo de receta. El software debe combinar el perfil interno, la identidad colegial y las restricciones que correspondan al producto o al profesional.

Resumen del procedimiento

La tabla no es un esquema teórico. Representa una secuencia de dependencias. Si falta cualquiera de los eslabones, la cadena no llega correctamente a la farmacia. Y si el proveedor no puede explicar en qué fase se encuentra, la clínica tampoco puede valorar de forma realista el riesgo del proyecto.

Seguridad no negociable: firma, cifrado, registros y Hoja de Información al Paciente

La homologación técnica y la homologación regulatoria comparten una misma base: la seguridad de la receta como documento y como acto clínico. Una receta electrónica no se valida por su apariencia, sino por la combinación de identidad, integridad, autenticidad y trazabilidad.

Firma electrónica avanzada o cualificada

El sistema exige el uso de una firma electrónica avanzada o cualificada por parte del prescriptor. La formulación importa: no debe presentarse la firma cualificada como la única opción admitida. El requisito es utilizar una firma electrónica avanzada o cualificada que cumpla las condiciones aplicables al sistema y permita vincular la receta con el profesional que la emite.

Cada receta debe incorporar una evidencia criptográfica asociada al proceso de firma y a la identidad del prescriptor. No se trata de pulsar un botón llamado «firmar» para que el programa guarde un PDF en una carpeta. La firma debe proteger la integridad del contenido y permitir comprobar que la receta no ha sido modificada después de su emisión.

Para la arquitectura del software, esto implica resolver varios asuntos que suelen quedar ocultos en las demostraciones comerciales:

• La identificación inequívoca del prescriptor que inicia la firma.
• La integración con el mecanismo de firma electrónica avanzada o cualificada elegido.
• La gestión del ciclo de vida del certificado o del medio de firma utilizado.
• La protección de las claves y de las credenciales asociadas al profesional.
• La confirmación explícita de la operación por parte del usuario autorizado.
• La posibilidad de verificar posteriormente la validez de la firma y la integridad del documento.
• La conservación de la evidencia vinculada a la receta, no solo del documento que ve el paciente.

La elección entre una firma electrónica avanzada o cualificada no debería hacerse por comodidad del proveedor ni por el nombre comercial de una plataforma. Debe responder a las exigencias del sistema, a la arquitectura de la clínica y a la forma en que se identifican los profesionales. Lo que no resulta aceptable es sustituir el requisito por una imagen de firma, una contraseña compartida o una simple marca en la interfaz.

Cifrado de las comunicaciones y registros de actividad

Las comunicaciones entre el software y NodoFarma, así como las que correspondan con los nodos de farmacia, deben viajar protegidas. El marco de seguridad contempla el cifrado en tránsito y, según la arquitectura, también la protección de los datos almacenados localmente o en los servicios intermedios.

El cifrado no resuelve por sí solo la seguridad de la integración. También hay que controlar qué sistemas pueden conectarse, qué credenciales utilizan, cómo se renuevan y qué ocurre cuando un certificado deja de ser válido. Una conexión cifrada con permisos excesivos sigue siendo un riesgo.

En paralelo, el sistema debe registrar la actividad relevante: quién prescribió, qué se prescribió, cuándo se realizó la operación, con qué identidad y certificado, desde qué dispositivo o entorno se inició y cuál fue el resultado de la comunicación o de la dispensación. Los registros deben cubrir también las anulaciones, los errores, los reintentos y las consultas que puedan afectar a la trazabilidad.

Esos registros no son una herramienta de depuración reservada al equipo técnico. Son la pista de auditoría que puede resultar necesaria ante un incidente, una disputa o una inspección. Deben estar protegidos contra modificaciones indebidas, conservar una referencia temporal coherente y quedar vinculados a la receta y al usuario que ejecutó cada acción.

Si el sistema solo guarda el último estado de una receta, no hay trazabilidad suficiente. Una receta que aparece como anulada no cuenta toda la historia si no se puede saber quién solicitó la anulación, cuándo se produjo, si llegó a comunicarse al sistema de dispensación y qué respuesta devolvió NodoFarma.

Generación de la Hoja de Información al Paciente

Cada receta debe generar la Hoja de Información al Paciente (HIP) con su código QR. Este documento acompaña al paciente hasta la farmacia y permite al farmacéutico dispensador validar la receta sin tener que acceder directamente al sistema interno del prescriptor.

La HIP no es una cortesía ni una plantilla que se añade al final del proyecto. Forma parte del resultado regulado de la prescripción. Debe presentar de manera comprensible la información que el paciente necesita y permitir la comprobación de la receta mediante el código correspondiente.

En el diseño del módulo conviene tratar la HIP como una salida de primera clase. Eso significa controlar cómo se genera, qué versión de los datos contiene, qué sucede si la receta se anula después de imprimirla y cómo se evita que una modificación posterior produzca una hoja que ya no corresponda con el registro válido.

La interfaz también tiene que prevenir errores de transcripción. Medicamento, presentación, pauta, fecha, identificación del profesional y datos de verificación deben proceder del mismo registro que se firma y se envía al sistema. Si la hoja se construye mediante un proceso separado, aparecen discrepancias difíciles de detectar: una pauta actualizada en la receta pero no en el documento, un código QR asociado a otro estado o una fecha que no coincide con la operación registrada.

En receta electrónica privada, lo que no se firma mediante un mecanismo válido ni deja un rastro verificable no se ha prescrito: se ha anotado.

Estupefacientes: el régimen especial que obliga a separar flujos

Existe una categoría de productos que no sigue exactamente el camino estándar: los estupefacientes y psicótropos sometidos a control especial. En este punto, el error más habitual consiste en tratar la diferencia como un simple campo adicional dentro del formulario común.

Lo que añade el Real Decreto 1675/2012

La dispensación de estupefacientes en receta electrónica privada debe cumplir los requisitos específicos fijados por el Real Decreto 1675/2012, de 14 de diciembre. Esa norma añade exigencias de identificación, conservación y trazabilidad sobre las aplicables a la receta común.

Para el software, esto se traduce en un flujo de prescripción diferenciado, con identificación reforzada del producto, comprobaciones adicionales de la habilitación y conservación de la información durante los periodos exigidos. También puede implicar comunicaciones o registros específicos ante la autoridad sanitaria, según el procedimiento que corresponda.

No basta con añadir una casilla que indique que el medicamento está sometido a control especial. El programa debe reconocer el tipo de producto, aplicar las reglas que procedan, impedir combinaciones no permitidas y generar la documentación exigible. Si el módulo trata los estupefacientes con la misma lógica genérica que una receta común, existe un problema regulatorio antes de la primera dispensación.

Implicaciones técnicas concretas

Separar el flujo de estupefacientes implica, entre otros aspectos:

• Identificar al prescriptor habilitado para este tipo de productos.
• Validar la habilitación específica antes de permitir la emisión.
• Aplicar las comprobaciones adicionales sobre medicamento, presentación y pauta.
• Generar la documentación para el paciente con los datos exigidos por el Real Decreto 1675/2012.
• Mantener la relación entre la receta, la hoja entregada y los eventos de dispensación.
• Conservar los registros durante el periodo que fija la norma, más allá de la retención típica de una receta común.
• Gestionar de forma diferenciada las anulaciones, correcciones y errores de comunicación.
• Evitar que un usuario pueda modificar los datos críticos sin repetir las validaciones y la firma correspondientes.

El mismo flujo no sirve para todo. Si se intenta adaptar el proceso común mediante una sucesión de indicadores y excepciones, la lógica condicional acaba siendo difícil de mantener y más difícil todavía de auditar. La separación debe existir en el modelo de datos, en las reglas de negocio, en los permisos y en los registros de actividad.

Cobertura real y preguntas que conviene formular

Antes de cerrar, merece la pena situar el SREP en contexto con algunos datos que la industria repite a veces sin matizar. El Sistema de Receta Electrónica Privada da cobertura a 9,2 millones de pacientes en España y está conectado con una red de más de 22.000 oficinas de farmacia a través de NodoFarma. Son cifras atribuidas al propio ámbito colegial y describen un sistema que opera a una escala suficiente como para que los problemas de interoperabilidad no puedan resolverse con procedimientos manuales.

Lo que esas cifras no dicen es igual de importante. No explican cuántas de esas farmacias dispensan efectivamente recetas privadas electrónicas, cuánto tarda en resolverse una incidencia o qué versión de las especificaciones técnicas está implementada en cada producto. Por eso, antes de contratar un software médico con receta electrónica, conviene preguntar:

• Qué alcance exacto tiene la homologación del producto y qué versión está cubierta.
• Si la integración incluye creación, consulta, anulación y seguimiento del estado de la receta.
• Cómo se verifica la habilitación profesional y qué ocurre si el servicio no responde.
• Qué tipo de firma electrónica avanzada o cualificada se utiliza y cómo se protege la evidencia.
• Cómo se conservan los registros de actividad y quién puede acceder a ellos.
• Qué sucede cuando NodoFarma devuelve un error o cuando la farmacia no confirma la operación.
• Cómo se genera la Hoja de Información al Paciente y cómo se invalida una copia impresa después de una anulación.
• Si el flujo de estupefacientes está realmente separado o solo se ha añadido un indicador al formulario común.
• Qué versiones de las especificaciones técnicas están implementadas y cuál es el procedimiento de actualización.
• Cuál es el tiempo de resolución de incidentes que afectan a la dispensación.

Estas preguntas incomodan, y por eso mismo son útiles. Separan el discurso comercial de la realidad operativa. Un proveedor serio puede explicar sus dependencias, sus límites y el procedimiento que sigue cuando algo falla. El que solo enseña una pantalla con un código QR todavía no ha demostrado una integración.

Lo que un desarrollador debería tener claro antes de empezar

La receta electrónica privada no es una funcionalidad que se añade al final de un proyecto clínico. Condiciona la identificación de usuarios, la arquitectura de seguridad, el modelo de datos, la relación con los colegios profesionales y el soporte que habrá que prestar después de la puesta en producción.

Hay cinco conclusiones que conviene mantener a la vista:

1. La receta electrónica privada no es una simple prestación del programa: es un sistema de interoperabilidad con gobernanza regulada por cuatro organizaciones profesionales.

2. Sin un expediente de homologación abierto ante el CGCOM, no existe una base administrativa sólida para avanzar hacia la integración técnica.

3. NodoFarma no es una API convencional para intercambiar documentos: participa en la validación de identidades, estados y eventos de dispensación.

4. La firma electrónica avanzada o cualificada y la verificación de la habilitación profesional forman parte del núcleo jurídico y técnico de la receta. No debe afirmarse que únicamente se admite la firma cualificada.

5. Los estupefacientes exigen un flujo específico y trazable, no una adaptación superficial del proceso ordinario.

Cualquier propuesta comercial que contradiga alguno de estos puntos es, por experiencia, más decoración que arquitectura. Como investigador acostumbrado a tratar con datos clínicos, lo que valoro de un sistema regulado es precisamente que la cadena esté documentada y pueda verificarse de extremo a extremo. El SREP, con todo el peso burocrático que arrastra, ofrece ese marco. La responsabilidad del proveedor consiste en implementarlo sin esconder las dependencias; la de la clínica, en no confundir una interfaz convincente con una integración homologada.