Portal de pacientes con citas online y telemedicina sobre Drupal: lo que aprendes después de quince años acompañando clínicas y hospitales

Llevo más de quince años trabajando con direcciones médicas y servicios de informática hospitalaria, y la conversación ha cambiado por completo. Hace una década había que justificar por qué una clínica necesitaba un canal digital para el paciente. Hoy ocurre lo contrario: el paciente da por hecho que podrá pedir cita, ver sus resultados y conectarse a una videoconsulta sin coger el teléfono. El Barómetro de Sanidad Digital 2025 de la Fundación IDIS pone número a esa intuición — el 73% de los pacientes españoles espera gestionar sus citas médicas online, y el 58% ya ha usado algún servicio de telemedicina en los últimos doce meses.

Que Drupal sea una buena base para construir ese portal de pacientes no es una opinión de consultor enamorado de su CMS. Lo usan la NHS británica, Pfizer, Johnson & Johnson y un buen número de hospitales universitarios europeos y americanos para sostener portales que mueven datos clínicos a diario. Los motivos son sosos pero importantes: arquitectura de permisos granular, multilingüe nativo, y un ecosistema de módulos suficiente para montar reserva de citas, historial clínico, videoconsulta y mensajería cifrada sin partir de cero.

Lo que viene a continuación es la guía que me habría gustado tener delante en mis primeros proyectos: requisitos normativos, arquitectura funcional, módulos concretos, integraciones de telemedicina y puesta en producción.

Marco normativo: el suelo del que parte cualquier portal sanitario en España

Antes de abrir un editor, conviene tener claro el terreno legal. La AEPD ha demostrado que las sanciones en sanidad no son simbólicas: hasta veinte millones de euros o el 4% de la facturación global. Y la dirección médica suele ser muy sensible a este punto, con razón.

RGPD y datos de salud

Los datos de salud son datos de categoría especial según el artículo 9 del RGPD. Su tratamiento exige:

• Base jurídica específica: consentimiento explícito del paciente o necesidad para la prestación de asistencia sanitaria (artículo 9.2.h).
• Evaluación de Impacto en Protección de Datos (EIPD): obligatoria cuando se tratan datos de salud a gran escala (artículo 35 RGPD).
• Delegado de Protección de Datos (DPO): obligatorio para centros sanitarios que traten datos de pacientes de forma sistemática.
• Registro de actividades de tratamiento: qué datos se recogen, con qué finalidad, quién accede y durante cuánto tiempo se conservan.

LOPDGDD

La Ley Orgánica 3/2018 complementa el RGPD en España con disposiciones específicas sobre datos de salud, incluido el cifrado de datos sensibles y la notificación de brechas de seguridad a la AEPD en un plazo máximo de 72 horas.

Esquema Nacional de Seguridad (ENS)

Si el portal presta servicios para entidades públicas (hospitales del SNS, conciertos con Seguridad Social), debe cumplir el ENS en el nivel que corresponda. Drupal aporta una buena base, pero la infraestructura de hosting tiene que estar igualmente certificada — un detalle que se olvida con frecuencia en pliegos mal redactados.

Normativa sanitaria específica

La Ley 41/2002 regula la autonomía del paciente y fija los requisitos del consentimiento informado digital. El Real Decreto 1093/2010 define las normas de interoperabilidad del SNS, relevante si el portal intercambia datos con la historia clínica electrónica (HCE) pública. Y el estándar HL7 FHIR es, hoy por hoy, el formato que permite que sistemas clínicos heterogéneos se entiendan entre sí.

Arquitectura funcional del portal de pacientes

Para una clínica o grupo hospitalario de tamaño medio, un portal de pacientes maduro suele tener estos bloques.

Área pública (sin autenticación)

• Información del centro: especialidades, equipo médico, ubicaciones, horarios.
• Buscador de profesionales con filtros por especialidad, idioma y disponibilidad.
• Contenido de educación sanitaria: artículos, guías, vídeos informativos.
• Formulario de primera consulta o solicitud de información.

Área privada del paciente (autenticado)

• Panel personal: datos demográficos, historial de visitas, próximas citas.
• Reserva de citas online: especialidad, profesional, fecha y hora con disponibilidad en tiempo real.
• Historial clínico resumido: informes de consulta, resultados de pruebas, prescripciones.
• Telemedicina: acceso a videoconsulta integrada en el portal.
• Mensajería segura: comunicación cifrada con el equipo médico.
• Documentación: subida de informes externos, consentimientos firmados, fotografías clínicas.
• Facturación: histórico de facturas, pagos online, datos de aseguradora.

Área del profesional sanitario

Agenda con vista diaria y semanal, ficha del paciente con historial y notas clínicas, inicio de videoconsulta desde la propia ficha y redacción de informes con plantillas por especialidad. Aquí merece la pena pelear el diseño con los facultativos: cada minuto que se les ahorra en clics se traduce en adherencia al sistema.

Módulos de Drupal que sostienen el portal

Gestión de usuarios y roles

Los roles granulares de Drupal encajan bien con la realidad de un centro sanitario:

• Paciente: acceso exclusivo a su propio perfil, citas, historial y mensajes.
• Profesional sanitario: acceso a fichas de sus pacientes asignados, agenda propia, redacción de informes.
• Administrativo: gestión de agendas de todos los profesionales, registro de nuevos pacientes, facturación.
• Administrador clínico: métricas, configuración de especialidades, gestión de plantillas.

El módulo Group permite crear contextos de acceso, por ejemplo una clínica con varias sedes donde cada una gestiona sus pacientes y profesionales sin ver los datos de las otras.

Profile y Field API

Profile, combinado con la Field API de Drupal, sostiene perfiles extendidos con campos específicos para un entorno clínico:

• Número de historia clínica.
• Fecha de nacimiento y edad calculada automáticamente.
• Grupo sanguíneo, alergias conocidas, medicación crónica.
• Datos de aseguradora y número de póliza.
• Consentimientos firmados con fecha y versión.

Reserva y gestión de citas

Las citas online son el corazón del portal. Hay tres caminos razonables, y la elección depende más de la organización del centro que de la tecnología.

Opción 1: Commerce + Booking (solución nativa)

Drupal Commerce con Commerce Booking o BAT (Booking and Availability Tools). BAT aporta un motor de disponibilidad que gestiona unidades reservables (consultas, boxes, equipos), estados (disponible, reservado, bloqueado) y reglas de duración por tipo de cita.

Una configuración típica define:

• Unidades: Consulta 1 Dr. García, Consulta 2 Dra. López, Sala Ecografía.
• Tipos de evento: Primera consulta (45 min), Revisión (20 min), Prueba diagnóstica (30 min).
• Horarios: lunes a viernes 9:00-14:00 y 16:00-20:00, con excepciones por festivos y vacaciones.
• Reglas: margen de 10 minutos entre citas, máximo 2 primeras consultas por franja horaria.

Opción 2: Integración con HIS/ERP externo

Cuando la clínica ya opera con un sistema de información hospitalaria — Selene de Siemens, HP-HIS, IMedical o Clinic Cloud — el portal de Drupal actúa como frontend que consume la API del HIS para mostrar disponibilidad y registrar citas. La integración se resuelve con módulos personalizados que dialogan con la API REST o SOAP del HIS. Es la opción habitual en hospitales públicos y en grupos privados consolidados.

Opción 3: Calendario con FullCalendar y reglas propias

Para centros pequeños, FullCalendar View con entidades de contenido personalizadas y el módulo Rules o ECA da para un sistema de reservas funcional sin dependencias externas.

Webform para formularios clínicos

Webform absorbe formularios de preconsulta (motivo, síntomas, duración), cuestionarios validados (escalas EVA, SF-36, PHQ-9), consentimiento informado digital con firma electrónica (Webform Signature Pad) y encuestas de satisfacción con envío automatizado 24 horas después de la consulta. Todos los envíos se almacenan cifrados y se vinculan al perfil del paciente.

Integración de telemedicina

Videoconsulta con Jitsi Meet

Jitsi Meet es la opción open source más madura para videoconsulta. Lo que la hace defendible ante un comité de seguridad:

• Sin instalación: funciona en el navegador (WebRTC), no hay que pelearse con ningún plugin.
• Autoalojable: se puede instalar en servidor propio dentro de la UE, lo que cierra la conversación sobre transferencias internacionales de datos.
• Cifrado extremo a extremo (E2EE): disponible desde Jitsi 2.0, de modo que ni el propio servidor de videoconferencia ve el contenido de la consulta.
• API JavaScript: permite embeber la videoconsulta dentro del portal como un iframe controlado, con los botones de inicio y fin integrados en la interfaz del profesional.

La integración con Drupal se resuelve con un módulo personalizado que genera salas únicas con tokens JWT por cita. A la hora marcada, paciente y profesional acceden desde su panel a un botón "Iniciar videoconsulta" que los conecta a la sala asignada.

Lanzamos un portal de pacientes para una clínica oftalmológica de Barcelona en 2023, y el reto no fue tecnológico: fue convencer al claustro médico de que una revisión de seguimiento de glaucoma podía hacerse por videoconsulta con la misma calidad asistencial que en gabinete. Una vez aceptaron pilotarlo con un solo facultativo durante seis semanas, los datos hablaron por sí solos y el resto del equipo se sumó sin resistencia.

Alternativas comerciales

Como alternativas a Jitsi, Whereby Embedded ofrece una API sencilla con servidores en Europa desde 10 euros por sala y mes. Twilio Video aporta más control programático para funcionalidades como grabación con consentimiento o compartición de pantalla. Zoom Healthcare garantiza cumplimiento RGPD con su plan sanitario y servidores en la UE.

Chat médico seguro

El módulo Private Message resuelve la mensajería interna asíncrona entre paciente y profesional. Para entorno sanitario, los mensajes se cifran con AES-256, se aplica retención configurable con eliminación automática y se registra auditoría de acceso a cada conversación.

Historial clínico y gestión documental

Modelo de datos para el historial

El historial clínico del paciente en Drupal se modela como una serie de entidades de contenido vinculadas al perfil del paciente:

• Consulta/Visita: tipo de contenido con campos para fecha, profesional, motivo, notas clínicas, diagnóstico codificado en CIE-10 y tratamiento prescrito.
• Resultado de prueba: tipo de prueba, fecha, resultado, archivo adjunto (PDF de analítica, imagen DICOM), profesional solicitante.
• Prescripción: medicamento, dosis, frecuencia, duración, profesional prescriptor.
• Documento clínico: informe de alta, interconsulta, consentimiento firmado.

Cada entidad hereda los permisos del perfil del paciente: solo el paciente propietario y los profesionales con asignación activa pueden acceder.

Interoperabilidad HL7 FHIR y PACS

Para centros con equipamiento de imagen médica, Drupal se integra con sistemas PACS mediante DICOMweb, y el visor OHIF permite ver estudios directamente en el portal. Para intercambiar datos clínicos con laboratorios, hospitales de referencia y aseguradoras, el servidor HAPI FHIR actúa como middleware exponiendo recursos estándar (Patient, Appointment, Observation, DiagnosticReport) a través de la API REST de Drupal. Si el centro va a interconectarse con la HCE pública, conviene revisar de cerca lo que prescribe el RD 1093/2010 sobre conjuntos mínimos de datos.

Pasarela de pago y facturación

Pago de consultas online

En clínica privada, integrar el pago en el flujo de reserva tiene un efecto medible sobre los no-shows. Los estudios del sector apuntan a reducciones de entre el 30% y el 50% cuando se cobra al confirmar la cita.

Drupal Commerce gestiona el cobro con las mismas pasarelas que cualquier e-commerce:

• Redsys: cobro con tarjeta bancaria española.
• Stripe: tarjetas internacionales y métodos de pago adicionales.
• Domiciliación SEPA: pacientes con tratamientos continuados y pagos periódicos.

Facturación automática

Commerce Invoice genera facturas con los datos fiscales del paciente y del centro. Para los centros que trabajan con aseguradoras, se implementa un flujo paralelo: la factura se emite a nombre de la aseguradora con los datos del paciente como beneficiario, siguiendo el baremo de la compañía.

Rendimiento, seguridad y hosting

Hosting conforme a normativa sanitaria

El hosting debe ubicarse en la UE — y de preferencia en España: Arsys, Acens, Stackscale, OVHcloud con datacenter en Madrid o Barcelona —, contar con certificaciones ISO 27001/27017/27018, ofrecer copias de seguridad cifradas con retención mínima de 5 años (Ley 41/2002) y un SLA del 99,9%.

Seguridad de la aplicación

• Autenticación reforzada: 2FA obligatoria para profesionales sanitarios mediante el módulo TFA de Drupal, con TOTP (Google Authenticator, Authy) o llaves de seguridad FIDO2.
• Cifrado en tránsito: TLS 1.3 obligatorio, con HSTS habilitado.
• Cifrado en reposo: datos clínicos cifrados en base de datos con AES-256. El módulo Field Encrypt de Drupal permite cifrar campos concretos de forma selectiva, que suele ser la estrategia más limpia.
• Auditoría de acceso: registro detallado de quién accede a qué ficha de paciente, cuándo y desde dónde. Audit Log y Watchdog dan esa funcionalidad.
• WAF: Web Application Firewall (Cloudflare WAF, AWS WAF o ModSecurity) para protegerse del OWASP Top 10.

Rendimiento

Las áreas públicas se cachean con Varnish, mientras que las privadas usan caché por usuario con invalidación selectiva. Los assets estáticos se sirven desde CDN con nodos en España (Cloudflare en Madrid y Barcelona), y herramientas como New Relic o Datadog supervisan el rendimiento con alertas si el tiempo de respuesta supera los 2 segundos.

Notificaciones y comunicación con el paciente

Recordatorios de cita

La reducción de no-shows es una prioridad operativa, no un capricho de marketing. Un esquema bien afinado incluye:

• Email 48 horas antes: confirmación con datos del profesional, ubicación y preparación necesaria (ayunas, documentación).
• SMS 2 horas antes: recordatorio breve con opción de cancelar o reprogramar mediante enlace. Integración con Twilio, Vonage o el español Altiria.
• Notificación push: si el portal tiene app móvil complementaria (PWA con Drupal o app nativa conectada vía API).

El módulo ECA o Rules de Drupal automatiza esos envíos sin intervención manual.

Resultados y seguimiento

Cuando un profesional carga un resultado de prueba o un informe, el paciente recibe un email con enlace seguro al portal que requiere autenticación y tiene caducidad configurable, por defecto 72 horas.

Accesibilidad y experiencia mobile-first

Drupal cumple WCAG 2.1 AA de forma nativa, pero la implementación concreta debe verificar contraste 4.5:1, navegación por teclado, textos alternativos, formularios con etiquetas asociadas y compatibilidad con lectores de pantalla (NVDA, JAWS, VoiceOver). El 68% de las reservas de citas online en España se hacen desde dispositivo móvil — datos de Doctoralia, 2025 —, así que el portal debe seguir un enfoque mobile-first con botones de tamaño suficiente y formularios adaptados.

Un caso real: clínica multiespecialidad en Madrid

Una clínica privada con 35 profesionales, 4 especialidades y 3 sedes en Madrid puso en marcha su portal con Drupal 10: reserva online integrada con Clinic Cloud vía API REST, telemedicina con Jitsi autoalojado en OVHcloud Madrid (un 22% de los seguimientos se hicieron por videoconsulta), historial clínico con descarga PDF y prepago Redsys que llevó los no-shows del 18% al 6%.

A los doce meses: 12.400 pacientes registrados, 87% de satisfacción y reducción del 40% en llamadas telefónicas. El proyecto se cerró en 18 semanas con tres desarrolladores Drupal, un diseñador UX sanitario y un consultor de cumplimiento.

Planificación del proyecto: qué esperar y cuánto cuesta

Construir un portal de pacientes con Drupal exige rigor técnico y conocimiento del sector. Las fases razonables siguen una secuencia lógica: auditoría de requisitos clínicos y normativos (3 semanas), diseño UX con validación de pacientes reales (3 semanas), desarrollo del núcleo — autenticación, perfiles, reserva de citas — (6 semanas), integración de telemedicina y pasarela de pago (4 semanas), testing de seguridad, auditoría RGPD y formación del equipo clínico (3 semanas).

La inversión se mueve entre 45.000 y 90.000 euros para una clínica de tamaño medio, frente a los 15.000-30.000 euros anuales de plataformas SaaS como Doctoralia Pro o Top Doctors, que no ofrecen el mismo nivel de personalización ni — y este punto es decisivo en sanidad — el mismo grado de control sobre los datos.

Si tu clínica u hospital está en ese momento en el que toca decidir entre alquilar la relación digital con el paciente o construirla sobre una base abierta y conforme a la normativa española, podemos sentarnos a dimensionar el proyecto desde la primera conversación, con calma y con los pies en el suelo que pide la HCE. Hablemos de tu portal de pacientes.