A patient persists. Each visit is a separate encounter.
SYSTEM
The database model is part of the product story.
The supplied SQL dump contains 43 tables. This page lets a technical reader inspect the conceptual groups without turning the public site into a raw SQL dump.
Patient identity & continuity10
patientsappointmentspatient_pmhpatient_chronic_conditionspatient_surgical_historypatient_home_medicationspatient_immunizationspatient_documentspatient_feedbackpatient_outreach_tasksPlatform foundation1
id_sequencesOPD & clinical care6
opd_visitsprescriptionsprescription_itemsprescription_templatesprescription_template_itemsicd10_codesMedicines & pediatric dosing2
medicine_mastermedicine_visibilityDiagnostics & laboratory7
investigation_masterinvestigation_panelsinvestigation_panel_itemsinvestigation_requestslab_orderslab_testslab_resultsPeople, locations & access15
clinicsclinic_locationsdepartmentsdoctor_defaultsdoctor_opd_locationsusersstaff_profilesstaff_credentialsstaff_documentsstaff_trainingstaff_financialstaff_clinical_privilegespermission_changesprofile_change_requestsuser_activity_logOutreach & communication4
patient_feedbackpatient_outreach_tasksbroadcast_templatesbroadcast_logClinical intelligence1
clinical_alertsRELATIONSHIPS
The interesting part is how the entities stay distinct.
These are the relationships that allow the workflow to scale without turning everything into one record or one status field.
A prescription belongs to the exact clinical encounter.
Orders point back to clinical context; results have their own lifecycle.
Dispensing is a later state, not an assumption made at prescribing.
Organization position, system role and capability remain separate.
Important changes leave an attributable history.