AIAZHEntidades Centrales y Relaciones
Toda base de datos HMS gira en torno al paciente. La tabla patients almacena datos demográficos, información de contacto y referencias al historial médico. Cada paciente puede tener múltiples citas, cada una vinculada a un médico específico (de la tabla staff con filtro de rol). La tabla appointments es la unión central — se conecta con facturación, recetas, órdenes de laboratorio y registros de visitas. Un esquema bien diseñado normaliza los datos al menos a 3NF para evitar redundancia mientras mantiene el rendimiento de consultas para operaciones diarias como búsqueda de citas y conciliación de facturación.
Tablas de Gestión de Pacientes
La tabla patients incluye campos como patient_id (PK), first_name, last_name, date_of_birth, gender, blood_group, phone, email, address, emergency_contact_name, emergency_contact_phone, y registration_date. Una tabla patient_medical_history separada registra diagnósticos previos, cirugías, alergias y enfermedades crónicas con claves foráneas hacia patient_id. Esta separación mantiene el registro principal del paciente ligero mientras permite entradas históricas ilimitadas. Para cumplimiento, cada registro debe incluir marcas de tiempo created_at y updated_at.
Esquema de Citas y Agenda
La tabla appointments es el corazón del HMS. Los campos incluyen appointment_id (PK), patient_id (FK), doctor_id (FK), appointment_date, appointment_time, status (scheduled/completed/cancelled/no-show), reason_for_visit, y notes. Una tabla doctor_schedule almacena ventanas de disponibilidad (doctor_id, day_of_week, start_time, end_time, slot_duration_minutes). El sistema genera los turnos disponibles cruzando el horario con las citas existentes para evitar doble reserva.
Facturación y Seguros
La tabla billing registra cada transacción financiera: bill_id (PK), appointment_id (FK), patient_id (FK), bill_date, total_amount, discount, tax, paid_amount, balance, y payment_status. Una tabla insurance_claims almacena detalles de póliza incluyendo provider_name, policy_number, coverage_percentage, claim_status, y claim_amount. Para escenarios complejos de facturación como cobertura parcial de seguro con copagos del paciente, el esquema soporta pagos divididos a través de una tabla payment_transactions que registra cada método de pago y su contribución a la factura.
Farmacia e Inventario
La tabla pharmacy_inventory gestiona medicamentos: item_id (PK), medicine_name, generic_name, category, manufacturer, batch_number, expiry_date, quantity_in_stock, unit_price, y reorder_level. Una tabla prescriptions conecta médicos con medicamentos: prescription_id (PK), appointment_id (FK), medicine_id (FK), dosage, frequency, duration, y instructions. Cuando se surte una receta, la cantidad en inventario se decrementa automáticamente y se activa una alerta de reorden cuando el stock cae por debajo del umbral.
Laboratorio y Diagnósticos
La tabla lab_orders registra los exámenes solicitados durante las citas: lab_order_id (PK), appointment_id (FK), test_name, test_category (blood/urine/imaging), ordered_by (doctor_id), order_date, status (pending/collected/processing/completed), y result_date. Una tabla lab_results almacena los valores reales: result_id (PK), lab_order_id (FK), parameter_name, parameter_value, normal_range, y interpretation. Para imágenes, una tabla radiology_images almacena referencias a archivos.
Gestión del Personal
La tabla staff unifica a todos los empleados del hospital: staff_id (PK), first_name, last_name, role (doctor/nurse/admin/lab_technician/pharmacist/receptionist), specialization, department_id (FK), phone, email, hire_date, y shift_preference. Una tabla departments lista las unidades del hospital (Cardiología, Traumatología, Urgencias, Radiología, etc.). La tabla staff_shifts asigna turnos reales: shift_id (PK), staff_id (FK), shift_date, start_time, end_time, y notes.
Mejores Prácticas para Diseño de Base de Datos HMS
Siempre usa UUIDs o claves primarias compuestas para sistemas distribuidos. Implementa eliminaciones suaves (flag is_active) en lugar de eliminaciones físicas para registros de pacientes. Añade restricciones a nivel de base de datos para campos críticos como unicidad de email del paciente y validación de hora de cita. Indexa columnas de claves foráneas que aparecen en operaciones JOIN — especialmente patient_id, doctor_id, y appointment_id. Para cumplimiento con HIPAA o regulaciones similares, añade una tabla audit_log que registre cada operación INSERT, UPDATE, y DELETE con user_id, marca de tiempo, y valores anterior/nuevo. Particiona tablas grandes como billing y lab_results por mes o año para mantener rendimiento de consultas a medida que crecen los datos.
