Sistema de prescripción médico - paciente Portugal

Una vacuna de inmunoterapia no se coge de una estantería. Se compone: el alergólogo elige presentación, tipo de tratamiento, los alérgenos a los que ese paciente está sensibilizado y en qué porcentaje entra cada uno. Lo que sale de la consulta no es un pedido de producto, es una fórmula con el nombre de una persona encima.

Y ahí estaba la condición que reorganizaba el sistema entero: en Portugal el médico prescribe, pero el que paga es el paciente. El pedido nace en una consulta y tiene que terminar en el teléfono de alguien que no estaba en esa habitación.

Una receta que sale de una consulta y tiene que llegar a un teléfono

El reto

• Un pedido, dos personas que nunca coinciden. El médico completa la prescripción y ahí acaba su parte. El dinero, la dirección de envío y la confirmación pertenecen al paciente, que no está delante. El pedido no puede grabarse y ya está: tiene que quedarse esperando, y saber qué está esperando.

• El paciente no tiene cuenta. A veces tampoco tiene email. Es fácil diseñar el flujo asumiendo que todo el mundo tiene correo. En una población de pacientes reales, repartida por todo Portugal, esa suposición deja gente fuera del tratamiento. Y un tratamiento que no se paga es un tratamiento que no se administra.

• La prescripción no es un producto: es una composición. Presentación —Depot, Polimerizado—, tratamiento de inicio o de continuación, alérgenos agrupados por familia y con valores por defecto según el producto, unidades y porcentajes. El formulario tenía que dejar prescribir rápido a quien sabe lo que hace, sin permitir combinaciones que no existen.

• Son datos de salud, no datos de cliente. Nombre, fecha de nacimiento, dirección, teléfono y los alérgenos concretos de una persona identificada. Eso es categoría especial del RGPD, y condiciona quién ve qué, qué viaja por SMS y qué se escribe en un PDF.

• Pagar en Portugal no es pagar con tarjeta. Dar por bueno el checkout que funciona en España es la forma más rápida de que la mitad de los pacientes no complete el pago.

• El papel no se rinde. Por muy buena que sea la plataforma, siguen llegando hojas de pedido rellenadas a mano.

La solución

— Acceso cerrado, sin registro

No hay alta pública. Los médicos los crea el laboratorio y entran con correo y contraseña; la plataforma no existe para nadie más. En un producto que maneja prescripciones, la puerta no se abre: se reparten llaves.

— La prescripción como formulario clínico

Tres apartados: historial, prescripción de inmunoterapia y prescripción de inmunoterapia bacteriana. El formulario recoge médico, clínica, referencia anterior, los datos del paciente y la composición —presentación, tratamiento, unidades, porcentajes, observaciones—, con los alérgenos agrupados por familia y los valores por defecto ya puestos según el producto.

Antes de grabar, el sistema pide confirmación explícita. Una prescripción mal enviada no se corrige con un botón de deshacer: se corrige llamando al laboratorio.

Del historial cuelga lo que de verdad usa un alergólogo a diario: repetir la vacuna de un paciente que continúa tratamiento, sin volver a componerla desde cero.

— El pedido que espera

Tramitado por el médico, el pedido queda en espera de pago. No es un carrito abandonado ni un borrador: es un estado legítimo del negocio, porque quien tiene que pagarlo todavía no se ha enterado de que existe.

Cuando el paciente paga, el cambio se refleja en el panel de administración y se notifica al laboratorio.

— El canal de contacto es parte del pedido

Al paciente con correo se le manda un email con el enlace a su prescripción. Al que no lo tiene, un SMS a través de Twilio con el resumen del pedido y el mismo enlace —con el campo de teléfono restringido a móviles portugueses, porque un SMS a un número mal formado se pierde en silencio y con coste.

Y lo que convierte esto en producto y no en un parche: la ficha del pedido registra por qué canal se comunicó, y ofrece un botón para reenviar la comunicación. Cuando el laboratorio llama a un paciente que dice no haber recibido nada, la respuesta está en la pantalla.

— El área del paciente, con el teléfono como identidad

El paciente entra de dos formas: por autologin desde el enlace que le llegó, o con su número de teléfono y una contraseña. El teléfono es obligatorio en el pedido precisamente porque es lo que vertebra su historial: es el único identificador que todos los pacientes tienen.

Dentro ve sus tratamientos, cuánto le queda del tratamiento en curso —la inmunoterapia dura años y esa es la pregunta que se hace un paciente— y el PDF de cada prescripción para consultarlo o descargarlo. Cuando su médico le crea un tratamiento nuevo, lo confirma, lo rechaza o lo paga desde ahí.

— Formas de pago portuguesas

Tarjeta, transferencia bancaria y Multibanco con pago por referencia y código. Multibanco no es una alternativa exótica: es como paga Portugal. Integrarlo no fue una mejora de conversión, fue la condición para que la plataforma funcionara en su país.

— La dirección la confirma quien recibe el paquete

Ante un pedido nuevo, el paciente puede modificar o confirmar su dirección de envío, y el panel de administración avisa de que ha habido cambio o confirmación. El médico no tiene por qué saber si su paciente se ha mudado.

— Triplicado, porque esto es farmacia

Impresión de la hoja para el paciente y del juego completo para paciente, médico y laboratorio. Un sistema digital en un entorno farmacéutico no elimina el papel: lo genera bien.

— Una puerta para las hojas de papel

En vez de pelearse con el canal antiguo, se le abrió una entrada: el paciente sube una foto de su hoja de pedido con su nombre, teléfono y correo, y eso genera una solicitud "pendiente de revisión" en un apartado propio del panel. Los gestores la marcan como leída y reciben aviso por correo de cada nueva entrada.

El papel deja de ser lo que se escapa del sistema y pasa a ser una bandeja de entrada más.

Stack

• Backend: Ruby on Rails

• Autenticación: Devise para médicos · autologin por enlace y teléfono + contraseña para pacientes

• Roles: médico / paciente / administrador y gestor de laboratorio

• Mensajería: Twilio (SMS) · correo transaccional

• Pagos: Multibanco (referencia y código) · tarjeta · transferencia

• Documentos: generación de PDF de prescripción y hojas para paciente, médico y laboratorio

• Base de datos: PostgreSQL

• Idioma del producto: portugués

Resultados

Antes, las prescripciones llegaban por correo electrónico. Y un correo electrónico no puede estar en espera de pago.

Ese es el resumen del cambio. Una bandeja de entrada no tiene estados: alguien del laboratorio tenía que leer cada mensaje, interpretar la composición escrita a mano o en texto libre, transcribirla, y después perseguir al paciente para el cobro y la dirección de envío. No había forma de saber cuántas prescripciones estaban pendientes de pago, ni de reenviar un aviso, ni de responder a un paciente que preguntaba por su tratamiento sin ponerse a buscar en el correo. Y todo ello con nombre, fecha de nacimiento, dirección y perfil de alérgenos —datos de salud— viviendo en bandejas de entrada.

La plataforma no sustituyó un formulario por otro: le dio estado a algo que no lo tenía.

Qué se llevó el cliente: una prescripción que sale de la consulta y llega hasta el pago sin que nadie tenga que perseguirla por teléfono. El laboratorio sabe en qué punto está cada pedido, por qué canal se avisó al paciente y quién confirmó la dirección a la que va la vacuna.