MedCES Application Overview
MedCES — the MStar Medical College Expert System — is the e-governance platform for an Indian medical college and its teaching hospital. It manages the learner’s institutional journey from counselling allotment to alumnus while keeping academic progression, statutory compliance, student services, and institutional administration connected.
MedCES is designed as a full medical-college ERP. It owns the college’s academic and administrative processes end to end, while exchanging defined data with the teaching hospital and external authorities. It does not manage patients or replace a hospital information system.
What MedCES is intended to achieve
Medical colleges often operate through disconnected registers, spreadsheets, portals, and office-specific systems. The result is repeated data entry, late discovery of academic risk, difficult inspections, and no continuous view of a learner’s progress.
MedCES brings these processes onto one institutional record so that:
- a learner has one identity across admission, study, internship, residency, and alumni life;
- academic progress is measured through curriculum delivery, attendance, assessment, and demonstrated competency;
- students, mentors, and administrators can see a risk while there is still time to act;
- regulatory reports are produced from everyday operational records rather than assembled only before an inspection;
- a college and its governing body can work from the same controlled source of information;
- every important decision retains its evidence, responsible actor, time, and audit history.
Application scope
MedCES supports the principal programme shapes found in a medical college:
| Programme shape | How progression is understood |
|---|---|
| MBBS | Progression through professional phases, subject to attendance, assessment, competency, and longitudinal requirements |
| Compulsory Rotating Medical Internship | Completion of required rotations, duties, leave adjustments, and certification |
| MD/MS and super-speciality programmes | Residency-year and rotation progression, with assessment, procedure, and thesis obligations |
| PhD | Progression through research milestones, reviews, publication requirements, and viva |
The applicable institute curriculum and rules are versioned by admission batch. A learner remains connected to the institute curriculum version under which they were admitted, even when newer batches follow a revised curriculum.
Who uses MedCES
MedCES presents different working surfaces over the same module base.
| Stakeholder | What MedCES helps them do |
|---|---|
| Student | Know where to be, what is complete, what is pending, and what may prevent progression |
| Teacher and clinical supervisor | Record teaching, attendance, observation, sign-off, assessment, and remediation without maintaining parallel registers |
| Alumnus | Request documents, complete credential verification, maintain outcomes, and remain connected to the institution |
| Institutional management | Operate the college, identify risk, monitor departments, and remain inspection-ready |
| Governance management | Review consistent information across one or more colleges without bypassing institutional responsibility |
Parent access is not a primary surface because medical learners are adults. Any access introduced later must be limited, consent-based, and focused on matters such as fees or emergency communication.
3L3T operating model
Every module operates across the same three organisational layers:
- Public or individual layer — the learner, teacher, alumnus, and other authorised individuals carrying out or receiving a service.
- Institutional layer — the medical college and teaching hospital as the operating institution.
- Administrative or governance layer — the trust, society, Directorate of Medical Education, university, or other authorised body overseeing one or more institutions.
The three access tiers position a grant at governance, institution, or operating-unit scope. Access is not determined by a role name alone. MedCES combines membership, core role, organisational scope, functional role, current assignment, and record state.
This allows the same application to support a single college and a multi-college governing body without exposing one institution’s operational data to another.
Understand the institutional hierarchy and access model →
Application structure
The functional application is organised into modules. The broader product responsibilities span academic operations, reporting and compliance, student life, and institutional administration. These responsibilities are separate from the three organisational access layers above.
- Layer 1 — Academic Engine: runs curriculum, delivery, progression, competency, assessment, research, and supervision.
- Layer 2 — Reporting & Compliance: derives regulatory evidence and management intelligence from operational records.
- Layer 3 — Student Life: manages admission and the non-academic services required throughout the learner lifecycle.
- Layer 4 — Institutional Administration: maintains the people, sites, documents, resources, and setup required to operate the institution.
Shared platform capabilities — identity, hierarchy, permissions, workflow, notifications, audit history, document storage, and integrations — support every module.
Documented modules
Only modules whose functionality has been discussed and agreed appear in this documentation. A module is added here when its foundations, actors, epics, and use cases are ready for review.
Setup
Establishes everything that must be defined before MedCES operational modules can safely use an institute, programme, course, curriculum, faculty association, facility, calendar, access grant, or controlled reference value. Tested programme packs supplied with MedCES create institute-owned programmes, courses, and Draft curriculum versions for the institute to review and publish. The module also shows what must be completed before operations can begin.
Student and Cohort Management
Creates the planned cohort for an institute programme and published curriculum, then maintains the student, programme-enrolment, and cohort relationships used by Admissions and academic modules. Its cohort dashboard brings together scoped admission, enrolment, phase, and academic summaries without duplicating their source records.
Open Student and Cohort Management →
Admissions
Receives external counselling allotments and turns a valid allotment into a verified, joined, and enrolled student. It covers admission cycles, seat matrices, counselling rounds, candidate reporting, verification, clearances, decisions, movement, reconciliation, and the handoff to the student record.
Academic Planning and Delivery
Turns a cohort’s published curriculum into dated academic work. It plans the phase, groups learners, schedules courses and clinical postings, publishes the master timetable, provides course and clinical-posting workspaces, records actual course and clinical delivery, and manages attendance.
Open Academic Planning and Delivery →
Competency and Logbook
Gives each learner one programme logbook with course, clinical-posting, elective, and longitudinal sections. Students submit contextual evidence, assigned faculty review it, Course Coordinators certify course-owned competencies, eligible unit or department faculty certify posting competencies, and coordinators close complete logbook sections.
Important product boundaries
MedCES owns the medical college as an educational and administrative institution. It deliberately does not own:
- patient registration, clinical care, hospital billing, pharmacy, diagnostics, or other hospital operations;
- payroll and full human-resource management;
- formal procurement conducted through government or trust systems;
- full learning-management capabilities such as SCORM, rich online-course authoring, video hosting, plagiarism checking, online assessment delivery, or a gradebook; MedCES provides lightweight course materials, announcements, discussions, and operational delivery records;
- counselling conducted by MCC, state authorities, universities, or other external bodies;
- university-side conduct of professional examinations.
These systems connect to MedCES through defined interfaces. Their source decisions are received and recorded; they are not silently recreated inside the college system.
How this documentation is organised
The documentation follows a consistent hierarchy:
Application → Module → Epic (a screen or coherent workspace) → Use case (a goal completed by an actor)Each module begins with its purpose, boundaries, actors, shared terms, lifecycle, recommended flow, and data model. Every epic then explains what must already exist, how the workspace operates, what the user enters, its use cases, business rules, acceptance criteria, exception paths, conceptual schema, and process-layer responsibilities.
The technical sections establish implementation intent and record ownership. Physical database migrations, detailed API contracts, and deployment instructions belong in separate engineering specifications.