Turned departmental practice into functional scope
Worked through how the block actually runs its projects, staff, meetings, seminars, documents, assets and notifications, and wrote that up as the functional scope.
Case study · AIIMS New Delhi · 2026
A single record of who works on what, where, and when.
The Mother & Child Block runs research projects with staff spread across several AIIMS sites. The platform replaces the registers, spreadsheets and email threads that used to hold that information with one role-based system — and, more importantly, with one agreed definition of every field in it.
In user acceptance testing · pre-release
The problem
Departmental research runs on records that nobody owns.
A research project generates far more than study data. It generates staff assignments, attendance, meeting minutes, seminar registers, asset lists and circulars — and in a department running many projects at once, each of those lives in a different spreadsheet with a different set of column names.
That is manageable until somebody asks a question that crosses the files. Who was assigned to this project in March. Which staff were present at the site that week. Where is the signed minute for the decision that changed the protocol. Answering takes days, and the answer is only as good as whoever last typed it.
The brief was not "build an app". It was: decide what each record means, who may see it, who may change it, and how anyone can tell afterwards that it was changed.
What I did
I sat between the investigators who needed the system and the technical team who built it. The specification was mine; the code was not.
Drafted the data dictionaries
Field-level definitions and validation rules for staff, project, asset and attendance records: mandatory fields, permissible values and duplicate prevention, agreed before build.
Defined who may see and change each record
The role-based access matrix, plus the audit-trail requirement that every change is attributable and traceable, alongside backup, retention and confidentiality rules.
Ran user acceptance testing
Testing with departmental users against real project staff records, logging defects and tracking each to closure before the platform is released to the department.
What the platform covers
Seven areas, each one a set of records with a defined owner and a defined audience.
Projects and project staff
Projects with duration, funding type and principal investigator; staff mapped to one or more projects, with assignment history retained rather than overwritten.
Location-based attendance
Attendance marked against permitted locations for staff working across several AIIMS sites, with exception handling and reporting on the result.
Meetings and minutes
Scheduled meetings with participants drawn from project and designation, attendance recorded against the meeting, and minutes held with version history.
Seminars and workshops
Event records with agenda and registration, and attendance captured at the event rather than reconstructed from a paper register afterwards.
Project documents
Project-wise storage for SOPs, protocols, guidelines and circulars, with role-based access and version history on every file.
Departmental assets
Asset records attributable to a project and a location instead of to institutional memory.
Role-targeted notifications
Meetings, task assignments, document updates and departmental announcements reach the roles they concern.
The data design
The part that outlives any particular screen.
Field-level validation
- Mandatory fields defined per record type, not left to the form designer
- Permissible values fixed as lists — designations, staff types, project status, locations
- Duplicate prevention on staff and project identifiers
- Date consistency checks, so an assignment cannot end before it starts
Access control
- A role matrix covering super administrator, department administrator, project coordinator and staff
- Project-scoped visibility: a coordinator sees their own project's staff and records
- Approval routing for attendance exceptions and manual overrides
- Administrative actions separated from data entry
Audit and retention
- Every record change attributable to a user and a timestamp
- Attendance modification history retained, including the approver
- Minutes and documents versioned rather than replaced
- Backup, retention and confidentiality rules written into the specification
Where it stands
The platform is in user acceptance testing with departmental users, checked against project staff records. Defects are logged and tracked to closure ahead of departmental release. It is not yet in general departmental use.
About the demo. The demo at aiimsmcb.manishabhardwaj.in is a separate build with sample data only — no AIIMS staff or patient records. Sign-in details are shown on its login screen.