BCBOT — SOP de Verificación de Elegibilidad

1. Cómo funciona (resumen del flujo diario)

A las 6:00pm el Task Scheduler lanza el robot, que hace todo solo:

2. Requisitos por cliente

• Máquina Windows en el consultorio con Dentrix instalado y funcionando (idealmente la del front-desk). Acceso remoto (RustDesk / AnyDesk / RDP) para administrarla.
• "Microsoft Print to PDF" disponible (viene con Windows 10/11).
• Cuenta Stedi (BC ClearingHouse) con API key de eligibility.
• Gmail con App Password de 16 caracteres (para mandar los emails).
• Datos del provider: NPI, TIN, razón social.

3. Instalación (una vez por cliente)

3.1 Software

pip install pdfplumber reportlab pypdf

3.2 Carpeta y archivos

1. Crear C:\BCBOT.
2. Copiar todos los archivos del sistema (ver §10) a C:\BCBOT.
3. Ajustar en run_robot.bat y run_daily.bat la ruta al python.exe del cliente.

3.3 Credenciales (archivos de texto, NUNCA en el código)

Crear en C:\BCBOT (Notepad → Guardar como, tipo "Todos los archivos"):

3.4 Config del provider

En fase0_build_270.py, editar el bloque PROVIDER:

PROVIDER = {
    "organizationName": "NOMBRE LEGAL DEL CONSULTORIO",
    "npi": "NPI_DEL_PROVIDER",
    "taxId": "TIN_SIN_GUION",
}

Y CLINIC en fase0_run.py (nombre corto que aparece en los emails).

4. Datos por cliente (roster + crosswalk de payers)

Esto es lo que hace que el robot verifique a la MAYORÍA, no solo a algunos.

4.1 Roster (member IDs) — reporte "Insurance Carrier List"

En Dentrix → Office Manager → Reports → Reference → Insurance Carrier List:

• Report Type: Dental
• Select Insurance Carrier: From <ALL> To <ALL> ← crítico, para traer TODOS los carriers
• List Types: Standard List + Include Subscribers
• Dejar destildado: Include All Insured Patients, Provider IDs, Mailing Labels
• OK → va al Batch Processor → abrir ese item → Print to PDF → guardar como roster_full.pdf

Parsear a cache:

python fase0_parse_roster.py roster_full.pdf roster_cache.json

Genera roster_cache.json (Chart# → member ID + payer ID + carrier). Refrescalo cada 1–3 meses o cuando entren muchos pacientes nuevos (los nuevos no aparecen hasta re-generar el roster).

4.2 Crosswalk de payers (nombre de carrier → payer ID de Stedi)

El payer ID del roster de Dentrix es basura ("SOURCE") en ~2/3 de los casos, así que el payer ID real se resuelve por el nombre del carrier:

• payer_map.csv — lista MAESTRA (carrier → payer ID de Stedi). Fuente principal; mantenela actualizada.
• carrier_to_payer_REVIEW.csv — crosswalk de los carriers del roster del cliente, auto-mapeado + revisado a mano (columna FINAL_PAYER_ID).

Prioridad de resolución del payer (ya implementada en fase0_build_270.py):

1. Payer REAL del roster del paciente (si es válido, no "SOURCE") — manda.
2. Crosswalk revisado por nombre (exacto o sin espacios: "Met life" = "MetLife").
3. Match contra payer_map.csv maestro (subset de tokens, seguro).
4. Crosswalk manual local.

4.3 Payers NO soportados por Stedi

En carrier_map.py, mantener la lista de carriers/payers que Stedi no soporta (ej. Solstice / 76578). Esos se escalan directo sin consultar (se verifican en el portal propio del payer). Agregá los que el cliente use y Stedi rechace.

4.4 Self-pay / Medicaid

Se detectan por nombre de carrier y se listan aparte (no se escalan como "falta dato") — no tienen seguro que verificar.

5. Convención de la nota "-BC"

El equipo marca las citas ya verificadas con "BC" suelto en la nota (cualquier variante: -BC, - BC, /BC, INS ACTIVE BC). El robot saltea esas y solo procesa las SIN marca. Entrenar al front-desk en esta convención es parte del onboarding.

6. Automatización

6.1 Auto-login de Windows (recomendado, para caídas)

Si la máquina se reinicia sola, Windows debe quedar logueado para que el robot pueda manejar ventanas. Configurar auto-login (netplwiz → destildar "Users must enter a user name and password", o AutoAdminLogon en el registro).

6.2 Tarea programada a las 6pm

En cmd (como admin):

schtasks /Create /TN "BCBOT Diario" /TR "C:\BCBOT\run_daily.bat" /SC DAILY /ST 18:00 /F

run_daily.bat lanza el robot en modo AUTO (sin carteles) que corre todo y cierra. La tarea es permanente: sobrevive reinicios y corre cada día sola.

7. Los 2 emails (salida diaria)

[ESCALACIÓN] {CLINIC} — {fecha}

Pacientes a resolver a mano, agrupados por motivo (no se pudo verificar / inactivo / payer no soportado / reintentar). El equipo los verifica manual y les pone "-BC".

[PDF PARA SUBIR {CLINIC} {fecha}]

Verificados OK, con los PDFs de cobertura adjuntos (logo de Stedi tapado) para subir al archivo del paciente en Dentrix.

Si el SMTP falla, los emails quedan en C:\BCBOT\out\ (email_1_escalacion.txt, email_2_pdfs_para_subir.txt) y los PDFs en out/ para mandarlos a mano.

8. Alertas

• Si el robot no puede abrir/loguear Dentrix → email [BCBOT ALERTA] a hello@brandacare.com (revisar la máquina por remoto).
• Si el PDF sale vacío (0 KB) → email de alerta (día sin pacientes, o algo se trabó).

9. Mantenimiento y troubleshooting

10. Inventario de archivos (C:\BCBOT)

Robot / automatización

Pipeline Python

Datos

Credenciales (§3.3) — 5 archivos .txt.
Salida — C:\BCBOT\out\ (logs, emails en .txt, PDFs de cobertura).

11. Checklist de onboarding de un cliente nuevo