MindFlow stores all patient data in a relational MySQL database with row-level encryption at rest. Every field that identifies a patient is treated as sensitive personal information under India's DPDP Act 2023. The system is designed to be the only clinical record you need open during a consultation.
Each patient has a single canonical record (patients table) linked to demographics, contacts, photo, and a free-form custom-fields JSON column. Relationships to appointments, notes, prescriptions, vitals, and assessments are all foreign-keyed to this record.
Patient photos are stored in the /uploads directory, outside the web root is recommended in production, served via api/patient_photo.php with session-based authentication — never via a guessable public URL.
Full-text patient search across name, UID, phone, and email. The patient_search_api.php endpoint returns JSON and powers the live-search typeahead used everywhere in the app.
Clinic-specific additional fields are stored as a validated JSON object per patient — no schema migration required to add new intake fields.
Notes are stored in clinical_notes with a companion clinical_note_versions table. Every save creates an immutable version row — the current note is always the latest version, but the full history is queryable.
Notes can be digitally signed by the attending clinician. Once signed, the note is locked; an amendment creates a new version linked to the signed original. Signature metadata (user ID, timestamp, IP) is stored alongside the note.
Integrated with the AI Copilot pipeline via api/ai_notewriter.php — takes structured session data and returns a draft note for the clinician to review and sign. The draft is never auto-saved; explicit clinician approval is required.
The includes/clinical_critical_values.php module defines configurable thresholds (e.g., suicidal ideation flagged in assessment, extreme vital reading). Crossing a threshold raises a notification via the notification_queue table.
ICD-11 (International Classification of Diseases, 11th Revision) — the WHO standard, mandatory for ABDM/FHIR record exchange in India. The app integrates with the official WHO ICD-11 API (icd.who.int).
Codes are fetched live from the WHO ICD-11 API using an OAuth2 client_credentials flow. Client ID and secret can be supplied by the hoster (plan-included) or by the clinic (bring-your-own). Responses are cached locally to avoid repeated round-trips during a consultation.
Each diagnosis row stores the ICD-11 stem code, the linearisation URI, the display term, and a free-text clinical modifier. Multiple diagnoses per note are supported.
Diagnoses are exported as FHIR Condition resources with coding.system = "http://id.who.int/icd/release/11/mms" when FHIR export is triggered.
PHQ-9, GAD-7, HAM-D (17-item), YMRS, PANSS (positive/negative/general), MDQ (Mood Disorder Questionnaire), AUDIT (Alcohol Use), and more. Scores are computed server-side; risk thresholds defined in includes/scale_risk.php trigger automatic alerts.
Clinics can define their own questionnaires in the custom_scales table (question text, response options, weights, total-score formula). Custom scales appear alongside built-in ones in the assessment workflow.
A clinician can send an assessment to the patient to complete from their portal (assessment_requests table). Completion status and score are fed back to the patient's record automatically.
The includes/scale_risk.php module defines per-scale risk bands (e.g., PHQ-9 ≥ 20 = severe). Breaches raise a notification and are visible on the patient overview.
prescriptions → prescription_groups → prescription_items. Groups allow multi-drug prescriptions with per-item dose, frequency, duration, route, and instructions. The prescription_labs and prescription_vitals tables link lab orders and vitals readings directly to a prescription.
The prescription-print.php page renders a print-ready prescription using the clinic's chosen letterhead (configured in Settings → Prescription Design). CSS @media print stylesheets control layout; PDF generation can be done browser-side or via a headless-print pipeline if configured.
api/voxrx.php accepts an audio blob, sends it to Sarvam AI's speech-to-text endpoint, then passes the transcript to the AI pipeline to extract drug name, dose, frequency, and instructions as structured JSON. The clinician reviews and confirms before the prescription is saved.
The medication_library table is a pre-seeded drug master (name, generic, common doses, frequency options) that powers the autocomplete when adding items to a prescription.
The vital_types table is configurable — admins define which readings (BP systolic/diastolic, pulse, weight, BMI, SpO₂, temperature, random blood sugar, etc.) are active for their clinic, with unit and normal-range metadata.
patient_vital_thresholds stores overrides per patient per vital type — useful for patients where the normal range is clinically different (e.g., a known hypertensive).
Google Fit (api/google_fit.php) and Apple Health (api/apple_health_sync.php) tokens are stored per patient in patient_google_fit_tokens and patient_apple_health_tokens. Sync is triggered on portal login and on a scheduled cron job.
The demo has real sample data — appointments, patients, prescriptions — so you can explore freely.