Errores comunes en tech stack clínica privada · 10 patterns a evitar 2026

La clínica privada media en España corre con un tech stack que se construyó por acumulación · no por diseño. Cada vendor llegó por un comercial · cada integración se hizo a mano · y nadie ha pensado en exit strategy cuando un proveedor sube precios o cierra. Estos son los 10 errores más comunes que veo · y framework para tomar decisión cada uno.

Error 1 · Vendor lock-in con un único PMS

El PMS (Practice Management System) suele ser el corazón: ficha clínica · agenda · facturación · historial. Cuando te casas con un único vendor sin pensar en salida · las consecuencias salen meses después.

• Síntoma: intentas cambiar de Dentaltec a otro y descubres que los datos están en formato propietario · sin export limpio · y el vendor cobra 500-1500€ por "asistencia migración".
• Framework: antes de firmar PMS · pide por contrato: (a) export completo en CSV/JSON · (b) derecho gratuito de extracción si abandonas · (c) formato documentado de cada tabla · (d) plazo máximo entrega 30 días.

Error 2 · No tener ownership real de tus datos

Casi todos los SaaS clínica te dicen "tus datos son tuyos". Casi ninguno lo demuestra con DPA claro + procedimiento export ágil + backups bajo tu control.

• Síntoma: vendor sufre incidente / cierra / sube precios brutalmente · y tú no tienes copia local reciente.
• Framework: backup mensual programado a storage propio (Google Drive / Dropbox / NAS) en formato legible (CSV · PDF informes · ZIP histórico). Verifica que el backup se puede restaurar (haz prueba real una vez al año).

Error 3 · Frankenstein con 8 vendors mal integrados

Doctoralia para agenda · Patient para facturación · Gesden para ficha · Mailchimp para email · Hubspot CRM · WhatsApp Business app personal del doctor · Excel para todo lo demás. Resultado: nadie sabe dónde está la verdad sobre un paciente.

• Síntoma: el teléfono de un paciente está actualizado en Doctoralia pero NO en Gesden. Manda recordatorio al número antiguo. No-show.
• Framework: define una "source of truth" para cada tipo de dato. Datos personales → PMS único. Pago → Stripe. Comunicación → un solo canal automatizado. Resto debe leer de la fuente · nunca duplicar.

Error 4 · Over-engineering en clínica single-doctor

El opuesto. Clínica de 1 doctor compra el stack que usaría una cadena de 20 clínicas: Salesforce + Marketing Cloud + BI tool + helpdesk · 800€/mes · usa 3% de las funciones.

• Síntoma: 80% del gasto en herramientas infrautilizadas. Recepción usa el 10% de cada herramienta. Equipo abandona el sistema y vuelve a Excel.
• Framework: antes de comprar herramienta · pregunta "¿Qué problema concreto resuelve hoy?". Si no tienes respuesta de 1 frase · no la necesitas. Empieza free tier · escala cuando duela.

Error 5 · WhatsApp personal del doctor cuando ya creció

Funciona los primeros 50 pacientes/mes. A partir de 200 · el doctor pasa 2-3 horas/día respondiendo · pierde productividad clínica · y el día que se va de vacaciones se paraliza la comunicación.

• Síntoma: doctor contestando WhatsApps a las 23:30. Pacientes esperando 6h respuesta. Confusión entre WhatsApp personal y profesional.
• Framework: umbral migración WhatsApp Business API: 150-200 mensajes/mes · o cuando el doctor empieza a perder consultas por responder mensajes · lo que ocurra antes.

Error 6 · Sin DPA firmada con processors

Cada vendor que procesa datos de pacientes (PMS · email tool · WhatsApp provider · backup cloud · analytics) es un Article 28 RGPD processor · y necesita DPA (Data Processing Agreement) firmado. La mayoría de clínicas no lo tiene · la AEPD puede multar.

• Síntoma: auditoría AEPD · reclamación paciente · respondes "tengo Mailchimp pero no tengo DPA firmado". Sanción posible.
• Framework: haz inventario de TODOS los vendors que ven datos paciente (incluye Google Workspace · Microsoft 365 · Stripe · etc.). Para cada uno · descarga DPA pública del vendor · firma y archiva. Vendor sin DPA disponible → red flag · considera reemplazo.

Error 7 · Compliance reactivo · no proactivo

"Cuando llegue la inspección AEPD · ya lo organizamos". Cuando llega · ya es tarde. La AEPD pide documentación que debe existir desde antes (Registro Actividades · Análisis Riesgos · DPIA si procede · etc.).

• Síntoma: reclamación paciente. AEPD pide Registro Actividades. No lo tienes. Procedimiento iniciado.
• Framework: dedica 2-3 días/año a compliance proactivo. Registro Actividades documento vivo · revisado anualmente. DPIA inicial cuando montas clínica · actualizada cuando cambias procesos relevantes.

Error 8 · Skip pen test cuando llegas a cierto tamaño

Clínica con 5+ doctores · > 5000 pacientes activos · ticket medio > 500€ · ya es objetivo de actores maliciosos. Datos sanitarios se venden en dark web · ransomware ataca clínicas regularmente.

• Síntoma: ataque ransomware bloquea PMS · 0 acceso fichas paciente · clínica parada 5-10 días · rescate 30-100k€ o pérdida total datos.
• Framework: a partir de 5+ doctores · contrata pen test anual (~3-5k€). Pequeño coste vs riesgo real. Empresa española ejemplo: Tarlogic · S2 Grupo · Internet Security Auditors.

Error 9 · Ignorar audit log retention

¿Quién entró en la ficha del paciente Juan Pérez ayer a las 16:30? Si no puedes responder con timestamp y usuario · tienes problema legal (LOPDGDD Art. 11) y de seguridad.

• Síntoma: ex-empleado descontento descarga base datos pacientes el día antes de irse. No te enteras hasta meses después.
• Framework: exige audit log a tu PMS con retención mínima 12 meses · acción · usuario · timestamp. Revisa muestra mensual (5 min/mes). Vendor sin audit log decente · no apto para clínica.

Error 10 · Sin exit strategy plan

Vendor cierra · sube precios 300% · te traspasa a competidor · cambia ToS desfavorable. La pregunta correcta no es "¿me pasará?" · sino "¿qué hago cuando pase?".

• Síntoma: vendor anuncia subida 200% precios. 30 días para decidir. Sin plan B preparado. Sin presupuesto migración. Tragas la subida o quemas semana migrando con urgencia.
• Framework: para cada vendor crítico · documenta en 1 página: (a) qué hace · (b) alternativas viables conocidas · (c) coste estimado migración · (d) plazo realista (4-12 semanas típico). Revisa anualmente. Mantén pulse de alternativas (reviews 1x/año).

Frameworks generales de decisión

El test 3-2-1 antes de añadir vendor

• 3 · ¿Tengo 3 alternativas evaluadas?
• 2 · ¿He hecho 2 demos · una con vendor · otra con cliente real de él?
• 1 · ¿Tengo 1 página de exit plan antes de firmar?

El test del "Bus factor"

Si tu único informático/admin de sistemas se va mañana · ¿la clínica sigue funcionando? Si la respuesta es no · tienes bus factor 1 · es riesgo crítico. Documenta accesos · passwords en gestor (1Password · Bitwarden) · procedimientos clave en wiki interna (Notion · GitHub Wiki).

El test "explica a tu sucesor"

Si tuvieras que vender la clínica mañana al doctor X · ¿le puedes pasar un documento de 1 página por sistema con: qué es · cómo se accede · quién lo paga · cuándo renueva · a quién llamar si falla? Si no · es un riesgo operacional pendiente.

Antes de comprar la próxima herramienta · 5 preguntas

1. ¿Qué dolor concreto resuelve hoy? (1 frase)
2. ¿Cuánto cuesta el dolor actual sin esta herramienta? (en € o en horas)
3. ¿Tengo DPA disponible · firmable y revisable?
4. ¿Cómo salgo si dentro de 1 año decido cambiar?
5. ¿Existe versión free / cheaper viable para validar primero?

Cómo AI Empire piensa estos errores

• Exportable · datos en Supabase tuya · acceso SQL directo vía solicitud · sin lock-in propietario.
• DPA Article 28 documento abierto · firmable en onboarding.
• Audit log nativo · todas las acciones registradas con timestamp + usuario · 12 meses retención mínima.
• Exit plan documentado · 30 días para extracción completa · gratuita.
• Single source of truth para comunicación paciente · evita frankenstein.

Disclaimer: este artículo es operativo general · no sustituye consultoría tecnológica · jurídica ni de ciberseguridad específica. La elección de tech stack clínico debe considerar tu volumen real · presupuesto · contexto regulatorio comunidad autónoma · y nivel de riesgo aceptable. Consulta con asesor cualificado antes de decisiones críticas.