AIAZHEntités Centrales et Relations
Toute base de données HMS tourne autour du patient. La table patients stocke les données démographiques, les informations de contact et les références d'historique médical. Chaque patient peut avoir plusieurs rendez-vous, chacun lié à un médecin spécifique (de la table staff avec un filtre de rôle). La table appointments est la jonction centrale — elle se connecte à la facturation, aux ordonnances, aux commandes de laboratoire et aux dossiers de visite. Un schéma bien conçu normalise les données en au moins 3NF pour éviter la redondance tout en maintenant les performances de requête pour les opérations quotidiennes.
Tables de Gestion des Patients
La table patients comprend des champs comme patient_id (PK), first_name, last_name, date_of_birth, gender, blood_group, phone, email, address, emergency_contact_name, emergency_contact_phone et registration_date. Une table patient_medical_history suit les diagnostics passés, les chirurgies, les allergies et les conditions chroniques avec des clés étrangères retournant à patient_id. Cette séparation garde le dossier patient principal léger tout en permettant des entrées historiques illimitées. Pour la conformité, chaque entrée doit inclure des horodatages created_at et updated_at.
Schéma de Rendez-vous et de Planification
La table appointments est le cœur du HMS. Les champs incluent appointment_id (PK), patient_id (FK), doctor_id (FK), appointment_date, appointment_time, status (scheduled/completed/cancelled/no-show), reason_for_visit et notes. Une table doctor_schedule stocke les créneaux de disponibilité (doctor_id, day_of_week, start_time, end_time, slot_duration_minutes). Le système génère les créneaux horaires disponibles en croisant le planning avec les rendez-vous existants pour éviter les doubles réservations.
Facturation et Assurance
La table billing suit chaque transaction financière : bill_id (PK), appointment_id (FK), patient_id (FK), bill_date, total_amount, discount, tax, paid_amount, balance et payment_status. Une table insurance_claims stocke les détails de la police incluant provider_name, policy_number, coverage_percentage, claim_status et claim_amount. Pour les scénarios de facturation complexes comme la couverture partielle d'assurance avec les copaiements patients, le schéma prend en charge les paiements fractionnés via une table payment_transactions.
Pharmacie et Inventaire
La table pharmacy_inventory gère les médicaments : item_id (PK), medicine_name, generic_name, category, manufacturer, batch_number, expiry_date, quantity_in_stock, unit_price et reorder_level. Une table prescriptions connecte les médecins aux médicaments : prescription_id (PK), appointment_id (FK), medicine_id (FK), dosage, frequency, duration et instructions. Lorsqu'une ordonnance est remplie, la quantité de l'inventaire est décrémentée automatiquement et déclenche une alerte de réapprovisionnement lorsque le stock tombe en dessous du seuil.
Laboratoire et Diagnostics
La table lab_orders enregistre les tests demandés lors des rendez-vous : 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) et result_date. Une table lab_results stocke les valeurs réelles : result_id (PK), lab_order_id (FK), parameter_name, parameter_value, normal_range et interpretation. Pour l'imagerie, une table radiology_images stocke les références de fichiers.
Gestion du Personnel
La table staff unifie tous les employés de l'hôpital : staff_id (PK), first_name, last_name, role (doctor/nurse/admin/lab_technician/pharmacist/receptionist), specialization, department_id (FK), phone, email, hire_date et shift_preference. Une table departments répertorie les unités hospitalières (Cardiologie, Orthopédie, Urgences, Radiologie, etc.). La table staff_shifts attribue les vrais quarts de travail : shift_id (PK), staff_id (FK), shift_date, start_time, end_time et notes.
Meilleures Pratiques pour la Conception de Base de Données HMS
Utilisez toujours des UUIDs ou des clés primaires composites pour les systèmes distribués. Implémentez les suppressions logiques (drapeau is_active) au lieu des suppressions physiques pour les dossiers patients. Ajoutez des contraintes au niveau de la base de données pour les champs critiques comme l'unicité de l'email patient et la validation des horaires de rendez-vous. Indexez les colonnes de clés étrangères qui apparaissent dans les opérations JOIN — en particulier patient_id, doctor_id et appointment_id. Pour la conformité HIPAA ou les réglementations similaires, ajoutez une table audit_log qui enregistre chaque opération INSERT, UPDATE et DELETE avec l'user_id, l'horodatage et les anciennes/nouvelles valeurs. Partitionnez les grandes tables comme billing et lab_results par mois ou par an pour maintenir les performances de requête.
