Médico

TL;DR

Cuaderno clínico del médico: consultas, decisión de aptitud para entrenar, días de baja, alertas de jugadores cuyo retorno se cumple en ≤7 días, lesionados activos con fase RTP y vista epidemiológica de la temporada. También es donde el médico aprueba o rechaza las altas que pide el fisio.

Para comercial

Problema que resuelve: las consultas y las decisiones de aptitud suelen quedar en papel, WhatsApp del médico o un Excel paralelo. CÉNIT las deja trazables en la ficha del jugador y conectadas al status operativo (available / recovering / injured).
Casos de uso típicos: registrar visita, indicar días de baja, dejar el diagnóstico documentado, aprobar el alta cuando el fisio la solicita, mirar la epidemia de lesiones de la temporada.
Planes: gated por feature flag (ver gotcha en Limitaciones).
Diferenciador: vista de epidemiología agrupada por región corporal y tejido, alertas automáticas de retornos próximos (sin cron — se calcula en cada render comparando visit_date + days_off) y el flujo bidireccional con fisio.

Cómo lo usa el staff

Acceso y permisos

Roles con acceso: med, hop, dir, coord_form (shell nav).
Subsecciones: KPIs, consultas recientes, lesionados activos, timeline de lesiones últimos 12 meses, epidemiología, clearances pendientes.

Flujos paso a paso

Registrar consulta: jugador, fecha, tipo de visita, diagnóstico, tratamiento, apto/no apto y días de baja. Se guarda en medical_consultations. Si la consulta marca no apto, el sistema actualiza players.status a injured; si marca apto y el jugador estaba injured, pasa a recovering. Estados de suspensión o inactive nunca son tocados por el médico.
Aprobar/rechazar alta: en el panel “Clearances pendientes” (provienen del módulo Fisio). Aprobar marca la instancia del protocolo como completed_at = now() y registra clearance_by + notas. Rechazar deja la instancia abierta para seguir tratamiento.
Ver epidemiología: gráficos por región corporal, tipo de tejido, mecanismo y dónde ocurrió (entrenamiento/partido/otro). Datos de los últimos 500 registros de injuries.
Alertas de retorno: lista de jugadores cuya fecha estimada de retorno (visit_date + days_off) cae en los próximos 7 días — sin necesidad de marcarlos manualmente.

Configuración relacionada

Plan debe incluir el módulo (ver gotcha del feature flag más abajo).

FAQ / casos límite

Si el médico registra “apto” para un jugador en recovering, el status queda en recovering hasta que pase a available por flujo de fisio/rendimiento.

Cómo lo ve el jugador

Player surface: N/A. El jugador no accede al historial clínico. Si se decide en el futuro notificarle el alta, sería vía push o mensajería interna.

Datos y métricas

Tablas DB / RPCs

medical_consultations — visitas, diagnóstico, tratamiento, días de baja, apto.
injuries — historial de lesiones (campos body_region, tissue_type, mechanism, laterality, occurred_in, injury_date, actual_return, expected_return).
fisio_protocol_instances — fuente del flujo de clearances.
RPC get_active_injuries_with_rtp — lesionados activos con fase RTP.

Integraciones

Fisioterapia: recibe solicitudes de alta (clearance_status = 'requested') y devuelve aprobación o rechazo.
Plantel: la consulta sincroniza players.status cuando corresponde y revalida /dashboard/plantel/[id].
Dashboard: lesionados activos y retornos próximos alimentan los KPIs del shell principal.

Limitaciones / roadmap

Gotcha de feature flag: app/dashboard/medico/actions.ts:131 valida canUse(plan, 'module_physio') cuando debería ser module_medical. Esa feature no existe hoy en lib/plans.ts, así que se gatea con el flag del módulo de fisio. Sin impacto comercial (todos los planes activos tienen module_physio = true) pero queda como TODO documentado en PROJECT_STATE.md § “Bugs menores en el sistema de plans”.
No hay generación automática de informe clínico PDF — se hace desde el informe HoP semanal cuando aplica.
ai_post_injury_analysis está prometido en planes Pro/Enterprise pero no implementado (ver PROJECT_STATE.md § “Features prometidas pero NO IMPLEMENTADAS”).