Defined the three roles and what each one sees
Patient, clinician and administrator as separate permission sets over the same participant record, so the review view and the entry view cannot drift apart.
Case study · AIIMS New Delhi · 2026
A missed glucose reading should reach the clinician, not just leave a gap in the dataset.
SAM4GDM is a self-assessment and management application for pregnant women with a diabetic history — a group that needs close glycaemic surveillance right through pregnancy. It was specified as a research instrument first and a patient app second: every reading it collects has to survive analysis.
Prototype · seeded demo data · not in clinical use
The problem
Self-reported data degrades quietly.
Managing gestational diabetes depends on readings a patient takes at home, several times a day, for months. Between appointments the clinician sees none of it. What arrives at the next visit is a paper diary — transcribed late, sometimes reconstructed from memory, and with no way to tell a reading that was taken from one that was remembered.
For care, that means an out-of-range value can sit unseen for weeks. For research, it means a dataset with gaps that look like normal values. Neither is solved by collecting readings faster; both are solved by knowing, per reading, when it was taken, whether it fell inside the permitted range, and whether anyone has looked at it.
The design rule throughout: a gap in the data is itself a finding. Missed entries surface to the clinician rather than silently degrading the dataset.
What I did
Requirements and the clinical data specification for an in-house prototype, then acceptance of what was built against them.
Specified the glucometer reading
Value, timestamp, meal context and participant linkage, with permissible-range checks and automatic flagging of out-of-range readings for clinician review.
Designed reminders as a data-quality control
Prompts for dietary adherence, medication and insulin doses, and for entry of readings — so that what is not entered becomes visible rather than absent.
Specified what makes the data usable for research
Audit trails, activity logs, user and security management, backup, and structured export for analysis.
One reading, fully specified
The smallest unit in the system, and the one everything else is built on.
glucose_reading
Data dictionaryone row per reading; nothing is inferred
value
Blood glucose, numeric, mg/dLchecked against the permissible range for its slot; outside it, the record is flagged
slot
Fasting, after breakfast, after lunch, after dinnercarries the meal context the value has to be interpreted against
taken_at
Date and time of the readingrecorded by the device, not typed
participant
Linkage to the participant recordmandatory; a reading with no participant is not a reading
status
In range · above range · below rangeset automatically, surfaced to the clinician for review
missed
Whether the slot passed with no entrydistinguishes recorded adherence from reconstructed adherence
What the application covers
Scoped across the three roles. Everything below exists in the demo; what is still waiting on a shared server is marked "coming soon" inside it.
Reading entry and reminders
Glucometer entry with range checking at the point of entry, a week of readings as one ring, and reminders for readings, diet, medication and insulin.
Learning material
Dietary guidance and educational content managed centrally, so what a participant reads is a known version.
Review queue and patient list
Flagged readings and adherence gaps raised for attention; each participant's week, notes and prescriptions in one view.
Remote consultation
Audio or video consultation requested by the patient, with a queue, one call at a time per clinician, and an unanswered state after 30 minutes.
Users, roles and security
User and security management with role separation, so clinical data is reachable only by the role that needs it.
Audit, backup and export
Every export is itself an audit entry. Readings, users and the audit log export as CSV; a full snapshot as JSON.
Where it stands
SAM4GDM is a prototype. The requirements, data model, validation rules and governance modules are specified and built out as a working demonstration on seeded data. It has not been deployed clinically and holds no real patient data.
About the demo. Choose a role on the first screen. Data is generated and kept on your own device; nothing is sent anywhere.