Patient intake (pre-visita, conforme al RGPD)

Patient intake automatiza todo el camino pre-visit del paciente: desde el primer contacto hasta el expediente electrónico listo para la consulta. El agente de IA trabaja con cuestionarios, datos de seguros, fotos de documentos e historial médico: recopila, verifica y estructura sin la intervención del recepcionista.

Para la clínica esto significa que en el momento de llegada del paciente el médico abre la ficha completa, y la recepción no se ahoga en la introducción manual de datos.

Qué hace exactamente la automatización

1. Envía una invitación. El escenario arranca 48 horas antes de la consulta, envía un enlace seguro por SMS o email en el canal Communications, cubierto por un contrato de encargo del tratamiento.
2. Conduce un cuestionario adaptativo. El paciente responde sobre demografía, quejas, alergias y medicamentos. El agente adapta las preguntas al tipo de visita.
3. Extrae datos de documentos. Las fotos de la póliza de seguro, el ID, las referencias y los informes previos pasan por OCR y un modelo de visión: los campos necesarios se completan sin introducción manual.
4. Verifica la cobertura del seguro. Envía una consulta a la aseguradora y obtiene el estado de la póliza, el copago y las prestaciones cubiertas.
5. Clasifica el caso. El agente determina el tipo de visita (inicial, follow-up, urgente), realiza el triaje según las quejas y deriva al especialista adecuado.
6. Sincroniza Calendar. Confirma la franja horaria, bloquea la preparación, envía recordatorios con 24 y 2 horas de antelación.
7. Transfiere el expediente al EHR. El registro listo pasa a la ficha del paciente: el médico ve el documento completo antes del inicio de la consulta.
8. Registra los accesos a datos de salud. Cada acción con datos de salud queda anotada en un log inmutable para auditoría.

Qué no hace la automatización

• No establece diagnósticos ni toma decisiones médicas: la IA recopila datos, el médico interpreta.
• No funciona sin un contrato de encargo del tratamiento (art. 28 del RGPD) con los proveedores de IA, hosting y comunicaciones. Si el contrato no está firmado, no se puede lanzar.
• No cubre las consultas de telemedicina de serie: los protocolos de vídeo y la monitorización remota requieren una configuración separada.

A quién va dirigido

Clínicas de atención ambulatoria, donde la recepción está sobrecargada de introducción manual de datos y los errores en los datos de intake generan rechazos de las aseguradoras y retrabajos. El umbral mínimo es 500–800 visitas al mes para amortizar la capa de cumplimiento y la infraestructura. Un volumen menor es más eficiente cubrirlo con formularios web simples sin IA.

Según el caso publicado por AffixedAI (no es un cliente de Grow2), en una consulta dermatológica de 8 médicos el efecto fue de 185 000 $ al año con una inversión de 12 900 $: un ROI del 1334%. Lo clave no es la reducción de tiempo del 92% en sí, sino las horas liberadas del recepcionista que se pueden destinar a casos complejos: seguros no estándar, reclamaciones, seguimiento.

Técnicamente, Patient intake es una orquestación multietapa sobre el stack existente de la clínica. El agente de IA no reemplaza el EHR ni el sistema PM, sino que los complementa como un wrapper conforme al RGPD sobre un núcleo de vertical-SaaS.

Arquitectura del flujo

1. Trigger. El evento «paciente registrado» en el sistema PM envía un webhook: se inicia el escenario del agente.
2. Capa conversacional. El paciente interactúa a través de un portal web seguro o un canal de chat de Communications cubierto por un contrato de encargo del tratamiento. Sin inicio de sesión: el enlace es de un solo uso, vinculado al appointment ID.
3. Document AI. Las fotos cargadas pasan por OCR y un modelo de visión. De los documentos no estructurados se extraen campos: número de póliza, grupo, nombre del titular, fechas.
4. Validation. Los datos se verifican contra el formato (estructura de la póliza, exactitud de las fechas). Comparación con la base de datos de la clínica para detectar duplicados.
5. Classification agent. El agente de IA clasifica la visita según las quejas y la enruta a la especialización correspondiente. Con bajo confidence, fallback al recepcionista.
6. Integration bus. La estructura lista se envía al EHR a través de FHIR o HL7 API. Si el API directo no está disponible, el conector RPA transfiere los datos como bot-operador.
7. Audit log. Todas las acciones con datos de salud se registran en un log inmutable con user ID, timestamp y scope de acceso.

Componentes de la solución

Pasos de implantación

1. Semanas 1–2: discovery y contratos. Mapa del proceso as-is, inventario de formularios e integraciones. En paralelo, firma de los contratos de encargo del tratamiento con los proveedores.
2. Semana 2–3: infraestructura. VPC cerrada, cifrado at-rest e in-transit, role-based access, conexión de prueba al EHR.
3. Semanas 3–4: construcción del agente. Configuración del cuestionario para la especialización, ajuste de extraction-prompts, conexión al sistema PM, escenarios con datos sintéticos.
4. Semana 4: piloto. 1–2 médicos, 50–100 pacientes reales, verificación manual de calidad, calibración de umbrales de confidence para clasificación y extraction.
5. Tras el piloto: escalado a toda la clínica, auditorías trimestrales de protección de datos, retro con la recepción para iteración.

Límites de la automatización

El umbral de confidence es el parámetro clave. Cuando el valor está por debajo del ajuste (típicamente 0,85), el caso pasa a la cola del recepcionista. Es un compromiso entre automatización y precisión: es mejor retrasar el 5–7% de los casos complejos que omitir el 0,5% de errores en el EHR. En el caso de dermatología publicado por AffixedAI, el error rate bajó del 3,8% al 0,3%.

Para lanzar Patient intake hacen falta requisitos organizativos, jurídicos y técnicos. El trabajo principal no está dentro del agente de IA, sino en la capa de compliance e integraciones con EHR.

Datos y accesos:

• Contrato de encargo del tratamiento con el proveedor de IA, el hosting y el proveedor de comunicaciones, obligatorio según el RGPD.
• Acceso API a EHR mediante FHIR o HL7, o consentimiento para integración RPA en sistemas legacy.
• Formularios de intake actuales en cualquier formato (PDF, papel, web), para mantener el flujo habitual del paciente.
• Lista de fuentes de documentos: póliza de seguro, ID, volantes de derivación, informes de alta previos.
• Acceso configurado a la verificación de coberturas de las aseguradoras, o disposición para conectar uno de los proveedores estándar.
• Métricas de baseline: tiempo actual de intake, error rate, wait time, necesarias para comparar a los 30 y 90 días.

Equipo y procesos:

• Product owner por parte de la clínica: operations manager o administrator (4–8 horas a la semana en el piloto, 1–2 horas después).
• Delegado de Protección de Datos (DPD): revisa los contratos de encargo, valida los controles de seguridad y es responsable de la evaluación de impacto (EIPD).
• 1–2 médicos early adopters y un recepcionista para UAT, calibración del triaje y feedback sobre la experiencia del paciente.
• Slot semanal de retro en las primeras 8 semanas, crítico para la iteración y el cierre de edge cases.

Cronograma:

• 4–6 semanas desde la firma de los contratos de encargo hasta el piloto productivo con 1–2 médicos.
• Otras 2–4 semanas para escalar a toda la clínica con formación de los recepcionistas y adaptación a cada especialización.