Patient intake (pre-visit, HIPAA-compliant)

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 con cobertura HIPAA.
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 vision — los campos necesarios se completan sin introducción manual.
4. Verifica la cobertura del seguro. Envía una solicitud al servicio de clearing, obtiene el estado de la póliza, el co-pay y el eligibility.
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 eventos HIPAA. Cada acción con PHI queda anotada en un log inmutable para auditoría.

Qué no hace la automatización

• No establece diagnósticos ni toma decisiones médicas: el AI recopila datos, el médico interpreta.
• No funciona sin BAA (Business Associate Agreement) con los proveedores de AI, hosting y communications. Si el BAA no está firmado — no se puede lanzar.
• No cubre las visitas telehealth de serie: los protocolos video y el remote monitoring requieren una configuración separada.

A quién va dirigido

Clinics con formato outpatient, donde la recepción está sobrecargada de introducción manual de datos y los errores en los datos de intake generan rechazos de seguros y retrabajos. El umbral mínimo es 500–800 visitas al mes para amortizar la capa BAA y la infraestructura. Un volumen menor es más eficiente cubrirlo con formularios web simples sin AI.

Para una práctica dermatológica de 8 médicos el efecto fue de $185K al año con una inversión de $12 900 — 1334% ROI. Lo clave no es la reducción de tiempo del 92% en sí, sino las horas liberadas del recepcionista que se destinaron a casos complejos: seguros no estándar, apelaciones, follow-up.

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 compatible con HIPAA 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 con cobertura BAA. 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 plan-holder, fechas.
4. Validation. Los datos se verifican contra el formato (estructura de la póliza, directorio NPI, 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 PHI se registran en un log inmutable con user ID, timestamp y scope de acceso.

Componentes de la solución

Pasos de implementación

1. Semanas 1–2: discovery y BAA. Mapa del proceso as-is, inventario de formularios e integraciones. En paralelo — firma del BAA 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 HIPAA, 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 demorar el 5–7% de los casos complejos que omitir el 0,5% de errores en el EHR. En la práctica dermatológica, el umbral se calibró hasta un error rate estable del 0,3% — una reducción desde el 3,8% inicial.

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:

• BAA (Business Associate Agreement) con el proveedor de IA, el hosting y el proveedor de communications — obligatorio según HIPAA.
• 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, referrals, informes de alta previos.
• Un servicio de clearing configurado para la verificación de seguros, 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).
• Privacy Officer — firma el BAA, valida los security controls, es responsable del HIPAA risk assessment.
• 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 del BAA 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.