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 curriculum and rules are versioned by admission batch. A learner remains connected to the regulation 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 v1 surface because medical learners are adults. Any future access is 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:

1. Public or individual layer — the learner, teacher, alumnus, and other authorised individuals carrying out or receiving a service.
2. Institutional layer — the medical college and teaching hospital as the operating institution.
3. 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 the user’s real-world role, capability grant, positioned entity, permitted descendants, 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 configuration 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.

M15 · Admissions & Enrolment

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.

Open the Admissions & Enrolment module →

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;
• learning-content authoring and delivery already provided by a learning platform;
• 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, access model, shared terms, and lifecycle. Every epic then explains the workspace, the actors who use it, its use cases, business rules, acceptance criteria, and important exception paths.

Detailed APIs, database fields, and deployment instructions belong in separate engineering specifications.