Compliance, data and what is not done yet.

No users and no outcome data

SynaptoFlow has not run a real surgical list. Nothing is known yet about its effect on cancellations or safety.

Clinical content not independently signed off

The symptom advice after surgery and the Urdu and Roman Urdu wording were written with care but have not been reviewed by an independent panel of surgeons, anaesthetists and Urdu-reading clinicians. That review is a condition of the first pilot.

No regulator opinion

We have not asked the Drug Regulatory Authority of Pakistan whether SynaptoFlow is a medical device under the Medical Devices Rules, 2017. Its intended purpose is administrative: it records answers and routes reports by rules written in advance, and makes no diagnosis or treatment recommendation. We will seek an opinion before any paid deployment.

No external penetration test

Security has been reviewed internally and the database rules are covered by automated tests that run against a real Postgres database. No independent firm has tested it.

Not incorporated

SynaptoNex is a trading name. Until it is incorporated, the contracting party is Dr. Shahbaz Waseem Gul personally.

Documents not reviewed by counsel

The privacy policy, terms and data processing agreement were drafted without review by a Pakistani lawyer.

No data protection statute

Pakistan has no data protection law in force. The draft Personal Data Protection Bill contemplates restrictions on transferring sensitive personal data abroad. If enacted in that form, hosting outside Pakistan may need to change.

Urgent alerts are email and screen only

An urgent patient report appears at the top of the worklist and is emailed to the care team, with retries every 30 minutes where the backstop job is set up. There is no SMS or phone escalation, and nobody at SynaptoNex watches the queue. Each unit must decide who reads these alerts out of hours before its first patient.

Restore not tested

Backups are those of the database plan the deployment uses (daily backups on Supabase paid plans). Restoring from a backup has not yet been rehearsed, and no recovery-time target has been agreed.

Regions we would consider

• Supabase

  Database and sign-in. Holds every patient record and the audit trail.

  Singapore

• Vercel

  Runs the website and server functions. Patient data passes through it; it is not stored there.

  Functions in the declared region; edge network worldwide

• Anthropic

  AI drafting, only when a clinician asks: checklist suggestions, Urdu translations and call scripts. Receives the procedure, the team’s instructions and checklist text, and for a call script which questions are unanswered or flagged, including any blood-thinner name the patient gave. The name, contact, MRN and date-of-birth fields are never sent; staff are asked not to type names into the text.

  United States

• Resend

  Email: patient links, reminders and care-team alerts. Care-team alerts name no patient.

  United States

• Twilio

  WhatsApp delivery of the patient link, only if switched on for the deployment.

  United States

Retention: While a practice uses SynaptoFlow, records are kept for seven years after the operation date. Then the name, date of birth, MRN, phone, email, the name of any relative who answered, and notes the patient typed are erased. The audit trail is kept: it holds no name, date of birth, MRN, full phone number or email from the record and no note the patient typed, but it does keep the answers, the time of each, a shortened internet address (the last part removed), and what staff wrote as clinical record (instructions, decisions, theatre notes, call logs). When a practice leaves, it receives a full export, and 90 days later its patients’ identifying details are erased the same way and its accounts closed.

• Staff accounts by invitation only, enforced by the sign-up hook and again by the database. Removing someone from the invitation list cuts off their access to patient records at once. Staff are signed out after 15 minutes idle.
• Row-level security in the database: one practice cannot read another's patients, and a care-team member reaches only the practices that added them.
• Patients reach their record only through a long random link token kept after the # in the address, never a record number. Links can be replaced or switched off, and stop working at the end of follow-up.
• Patient writes go through database functions that accept a fixed list of fields and stamp the server's time. Staff cannot write consent, approval or audit entries directly.
• Extra checklist items and Urdu or Roman Urdu translations reach a patient only after a named surgeon, anaesthetist or nurse approves them. Coordinators cannot approve. Editing them withdraws the approval, and a translation of English that has since changed is removed rather than left on the patient's screen.
• Saving checklist wording never overwrites a patient's ticks or notes. When staff record an answer for a patient, such as a clinic blood pressure, the audit trail shows it was staff.
• Urgent alerts cannot be switched off. A full data export is available only to the surgeon who owns the practice account.
• The only “fit to proceed” statement the record will print is a decision recorded by a named surgeon or anaesthetist.