Estructura de datos para citas: campos mínimos y normalización

La estructura de datos de citas es la base de cualquier agenda clínica o centro de salud. Si los campos no están bien definidos, tú sufres con duplicidades, reportes inconsistentes y fricción entre equipos. Peor: las integraciones fallan y el paciente recibe recordatorios en horas equivocadas.

En este artículo te doy un marco mínimo y práctico: qué campos debes capturar, cómo aplicar normalización sin complicarte, qué identificadores usar para evitar colisiones y cómo manejar fechas y zonas horarias con seguridad. Está pensado para un perfil analista/operacional que necesita padronizar datos y ganar confiabilidad.

Nota: respeta la privacidad y las normativas locales. Esto no es asesoría legal.

Resumen accionable

• Define un diccionario de datos con naming consistente, tipos y ejemplos.
• Usa un id_cita único, inmutable, no significativo y generado por el sistema.
• Registra fechas en ISO 8601 y guarda explícitamente zona_horaria y offset.
• Normaliza pacientes, profesionales y servicios en tablas/colecciones separadas.
• Controla estados de la cita con un catálogo finito (p. ej., programada, atendida, cancelada).
• Traza el origen_lead y el consentimiento para auditoría.
• Implementa webhooks y logs para cambios de estado y reintentos idempotentes.
• Publica un CSV base para alineación entre sistemas (CTA: baixar CSV).

Campos

Para que los datos de agenda sean útiles y portables, necesitas un conjunto mínimo de campos estables. La idea es capturar lo esencial para operar, notificar y auditar, evitando sobrecarga inicial. A continuación te propongo un esquema mínimo que puedes ampliar según tu contexto. Usa nombres en minúsculas con guiones bajos y tipos explícitos (string, datetime, enum, bool).

Ejemplo de registro de cita (mínimo recomendado):

id_cita	fecha_hora_inicio (ISO)	zona_horaria	paciente_nombre	paciente_contacto	profesional	servicio	estado	origen_lead	consentimiento
cta_01H8Q3…	2025-10-09T14:30:00	America/Sao_Paulo	Ana Lima	+55-11-9…	Dr. Souza	Consulta general	programada	web_form	true

Campos clave (descripción breve):

• id_cita (string): identificador único, opaco, no reutilizable.
• fecha_hora_inicio (datetime ISO 8601): fecha y hora de inicio de la atención.
• zona_horaria (string IANA): p. ej., America/Sao_Paulo.
• paciente_nombre (string) y paciente_contacto (string): nombre y canal principal (teléfono o email).
• profesional (string/ID) y servicio (string/ID): referencia al recurso humano y al tipo de servicio.
• estado (enum): programada|confirmada|atendida|no_asistio|cancelada.
• origen_lead (enum/string): fuente de la cita (web_form, whatsapp, call_center, derivación).
• consentimiento (bool/timestamp): consentimiento válido para comunicaciones.

Tras definirlos, documenta: propósito, tipo, formato, ejemplo y reglas de validación. Esto habilita controles (p. ej., impedir citas sin zona_horaria) y hace tus reportes comparables entre clínicas o sistemas. Si necesitas extensiones (p. ej., sala, duración, observaciones), añádelas como opcionales y evita romper compatibilidad.

Transición: con estos campos mínimos consolidados, el siguiente paso es garantizar calidad y consistencia a través de normalización.

Normalización

La normalización evita redundancias y errores cuando la misma entidad aparece en múltiples citas. No es un fin en sí mismo: busca equilibrio entre integridad y desempeño. Para agenda clínica, apunta a 3ª forma normal (3FN) en entidades maestras y permite desnormalizaciones controladas en vistas operativas (dashboards, colas).

Diagrama ASCII (vista lógica simplificada):

[Paciente]----< tiene >----[Cita]----< realizada_por >----[Profesional]
     |                                   |
     +----< solicita >----[Servicio]-----+

Lineamientos prácticos:

• Pacientes, profesionales y servicios deben vivir en tablas/colecciones propias (maestros), con sus propios IDs.
• En Cita, guarda solo las claves (id_paciente, id_profesional, id_servicio) y los campos transaccionales (fechas, estado).
• Si necesitas mostrar paciente_nombre o servicio en reportes, crea vistas o materializaciones que se regeneren con cambios maestros.
• Mantén historial de cambios (quién, cuándo, qué) de estado y horario para auditoría y notificaciones.

Transición: con entidades separadas y claves consistentes, definimos cómo generar identificadores sin colisiones.

Identificadores

Un buen identificador evita dolores como citas duplicadas o referencias rotas en integraciones. Prefiere IDs opacos (sin significado de negocio), inmutables y suficientemente largos.

Recomendaciones:

• id_cita: UUID v7 o ULID (ordenable por tiempo), o un Snowflake de tu plataforma. No incluyas fecha o siglas de la clínica en el ID.
• Claves externas: cuando integres con terceros (p. ej., CRM), guarda id_cita_externo y mapea en una tabla de correspondencias para no contaminar tu modelo interno.
• Idempotencia: para webhooks y colas, genera un idempotency_key por operación (p. ej., “cita:cta_01H8Q3:confirmar:2025-10-09T10:00Z”) y rechaza reintentos duplicados.
• Secuencias legibles: si necesitas un “número de turno” visible, trátalo como atributo derivado que puede reiniciarse por día/sede, sin reemplazar el id_cita.

Transición: una vez resuelto “quién es quién”, toca lo más sensible en agendas: fechas y zonas horarias.

Fechas/Zonas

Las fechas en salud son críticas por notificaciones, asistencia y cumplimiento. La regla de oro: guarda la hora local exacta y su contexto de zona/offset, y conserva una proyección en UTC para cálculos.

Tabla comparativa (estrategias de almacenamiento de tiempo):

Estrategia	Qué guardas	Pros	Contras
Solo local	2025-10-09 14:30	Legible para operadores	Ambigua; falla en cambios de horario de verano
Solo UTC	2025-10-09T17:30:00Z	Cálculo y ordenamiento simples	Necesitas conocer la zona para mostrar al paciente
Local + zona + UTC (recomendada)	fecha_hora_inicio_local, zona_horaria, fecha_hora_inicio_utc	Desambiguada, fiable para notificar y auditar	Requiere validaciones y sincronía

Buenas prácticas:

• Usa IANA TZ (p. ej., America/Sao_Paulo) y registra el offset efectivo al agendar.
• Normaliza las entradas en ISO 8601. Valida que fecha_hora_inicio_utc corresponda al par (local + zona).
• Al mover una cita, recalcula coherentemente las tres vistas (local, zona, UTC) y registra un evento en el historial.
• Fija un timezone por defecto del país para la sede, pero permite override por teleconsulta o sedes fronterizas.
• En recordatorios, calcula la hora de envío en UTC a partir de la zona del paciente, con logs y alertas si la conversión falla.

Transición: con tiempos confiables, cerremos con una plantilla mínima que puedes convertir en CSV.

Errores comunes

• Usar IDs “bonitos” con significado y luego no poder cambiarlos.
• Guardar horas “a ojo” sin zona y caer en inconsistencias.
• Duplicar datos de paciente en cada cita y perder sincronía.
• Estados de cita abiertos sin catálogo claro.
• No versionar cambios ni registrar quién modificó qué.
• Integrar primero y modelar después (termina en mapeos frágiles).

Cierre: evita estos tropiezos aplicando el mínimo propuesto, y verás agendas más confiables, reportes comparables y menos retrabajo en integraciones.

Checklist / Plantilla mínima (versión resumida del CSV)

Encabezados sugeridos (en este orden):

id_cita,fecha_hora_inicio_local,fecha_hora_inicio_utc,zona_horaria,
id_paciente,paciente_nombre,paciente_contacto,
id_profesional,id_servicio,estado,origen_lead,consentimiento

Reglas de validación rápida:

• id_cita: string no vacío, único.
• fecha_hora_*: formato ISO 8601; coherencia entre local/UTC dado zona_horaria.
• zona_horaria: valor IANA válido.
• estado: uno de programada|confirmada|atendida|no_asistio|cancelada.
• consentimiento: true|false o timestamp ISO si guardas cuándo se obtuvo.

FAQ

1) ¿Puedo usar solo UTC y olvidarme de la zona?
Puedes, pero perderás contexto para el paciente y te complicas al mostrar la hora correcta. Recomendamos guardar local + zona + UTC.

2) ¿Qué pasa si una sede cambia de horario de verano?
Al tener zona_horaria IANA y offset efectivo, tus conversiones seguirán siendo correctas; asegúrate de recalcular proyecciones y registrar el evento.

3) ¿Cómo manejo la cancelación vs. no asistencia?
Mantén estados distintos y registra timestamps de cambio. Esto permite métricas y automatizaciones específicas (p. ej., reenganche para no asistencia).

4) ¿El consentimiento debe ser booleano o fecha?
Operativamente basta un booleano; para auditoría, es mejor timestamp y origen (p. ej., formulario web, firma digital).

5) ¿Qué identificador elegir: UUID o ULID?
Ambos sirven. ULID/UUIDv7 facilitan orden por tiempo; evita UUIDv1 si te preocupa filtrar metadatos.