Institute Programme Setup

Epic summary

The Institute Programme Setup workspace creates a programme inside one institute.

For example, it creates MBBS at Government Medical College Nagpur. It does not create one shared MBBS record that every institute must use.

An authorised user normally starts from a programme pack delivered with MedCES. The pack supplies a tested starting point. Installation copies the programme, suggested courses, curriculum structure, and requirements into institute-owned Draft records.

MBBS CBME pack in MedCES
  -> MBBS programme owned by Institute A
  -> institute courses
  -> Draft curriculum version

After installation, Admissions, cohorts, schedules, and learner records use the institute programme. They do not depend on a shared catalogue record.

Before you start

The institute must exist and be active. Its basic authority or affiliation information should be available. Departments should be created before pack installation where possible, although the installation wizard can also create suggested departments as Draft records for later review.

Actors and access

Access source	Access in this epic
Institute member with Academic Registrar role	Selects a pack, installs it, and completes programme details
Institute member with Curriculum Committee role	Reviews the selected pack and academic setup
Department Admin, normally with HOD appointment	Confirms suggested mappings for assigned departments
Institute member with Programme Approver role	Approves programme activation
Platform Admin	Makes released packs available but cannot activate an institute programme
Auditor role	Views pack source, institute changes, approvals, and history

What the user does

The workspace is a guided setup with six screens:

Select Programme Pack
Programme Details
Authorities and Approved Intake
Suggested Department Matching
Installation Preview
Review and Activation

Screen 1: Select Programme Pack

The user sees only packs supported by the running MedCES version.

Field	Required	What the user defines
Programme pack	Yes	For example, `MBBS - CBME 2024`
Pack version	Yes	Defaults to the latest supported version for a new installation
Programme	Inherited	Programme name and qualification supplied by the pack
Issuing authority	Inherited	Authority represented by the pack source
Applicable admission batches	Inherited	Applicability recorded in the pack
Source documents	Inherited	Regulations, notifications, and references packaged with the template

The screen explains what will be created before the user continues. Selecting a pack does not publish anything.

If no pack exists for a required programme, an authorised user may choose Create a local programme. That route creates a blank institute programme and curriculum. It uses the same review and publication controls.

Screen 2: Programme Details

The pack pre-fills the standard identity. The user confirms institute-specific information.

Field	Required	What the user defines
Institute programme code	Yes	Unique code inside the institute, such as `MBBS`
Programme name	Yes	Local display name
Qualification awarded	Yes	For example, Bachelor of Medicine and Bachelor of Surgery
Programme family	Yes	Undergraduate, postgraduate, super-speciality, doctoral, or another controlled type
Progression pattern	Yes	Phase-based, residency-year, rotation-based, research milestone, or another supported pattern
Standard academic duration	Yes	Overall expected duration; detailed stage duration belongs to the curriculum
Internship relationship	Yes	Included in the programme, follows the academic programme, or not applicable
Coordinating responsibility	Yes	Functional role accountable for programme coordination
Start and end dates	Yes/No	Date from which the institute operates the programme and optional closure date
Local award text	No	Institute-approved display text where permitted

The user does not define phases, competencies, postings, or examinations on this screen. Those are defined in the Curriculum Builder.

Screen 3: Authorities and Approved Intake

This screen records which existing authority relationships apply to the programme.

Field	Required	What the user defines
Regulator relationship	Conditional	Recognition or permission covering this programme
Affiliating/awarding university	Conditional	University or awarding body and relationship period
Examining authority	Conditional	Authority responsible for examinations
Approved intake	Conditional	Approved seats, effective admission year, end date, and source order
Recognition number	Conditional	Programme-specific identifier issued by the authority
Supporting document	Conditional	Approval, recognition, or affiliation evidence

Approved intake is effective-dated. A later change creates a new intake record; it does not overwrite the value used by an earlier admission cycle.

Screen 4: Suggested Department Matching

The pack can suggest departments such as Anatomy, Physiology, Biochemistry, General Medicine, and General Surgery.

For each suggestion, the user chooses one action:

match it to an existing institute department;
create a Draft institute department using the suggestion;
mark it as not applicable where the pack permits this; or
leave it unresolved and complete it later.

Field	Required	What the user defines
Suggested department	Inherited	Stable pack item and suggested name
Institute department	Conditional	Existing department selected by the user
Action	Yes	Match, create draft, not applicable, or unresolved
Local name/code	Conditional	Used when a Draft department is created
Reason	Conditional	Required for permitted not-applicable decisions

Department matching prepares course ownership. It does not grant access to a department or to its faculty.

Screen 5: Installation Preview

Before creating records, MedCES shows:

the institute programme that will be created;
institute courses that will be created;
the Draft curriculum version and its stages;
the number of competencies, postings, assessments, and rules;
departments that will be matched or created;
unresolved information requiring institute action;
existing records that could conflict with the installation.

The user confirms the preview. Installation is safe to retry and cannot create a second copy of the same pack version for the same institute programme.

Screen 6: Review and Activation

After installation, the programme remains Draft. The user completes missing authority and department information, then submits it for review.

Activation makes the programme available for curriculum publication and admission-cycle planning. It does not automatically publish the Draft curriculum created from the pack.

Worked example: Set up MBBS

Government Medical College Nagpur selects MBBS - CBME 2024, pack version 1.2.0.

The registrar confirms the local code MBBS and the Academic Registrar coordination responsibility.
The NMC recognition and affiliating-university relationships are selected.
Approved intake of 200 seats is recorded from the applicable order.
Pack suggestion department.anatomy is matched to the institute’s Department of Anatomy.
department.aetcom is not created because AETCOM is delivered across departments and the pack permits no dedicated department.
MedCES creates the institute programme, courses, and Draft CBME 2024 curriculum version.
An authorised Programme Approver, who may hold the Dean appointment, approves the programme. The academic team continues in Course Catalogue and Curriculum Builder.

Use case 1: Install a programme pack

As an institute member with Academic Registrar role
I want to install a released programme pack into my institute
So that I begin with a complete, tested academic structure.

Acceptance criteria

Only packs supported by the current MedCES version can be selected.
The user sees the pack version, source, applicability, and installation contents.
Installation creates records owned by the selected institute.
No created academic record has a runtime foreign key to a shared programme or curriculum row.
A repeated request with the same installation key does not create duplicates.
All created records remain Draft until reviewed and approved.

Use case 2: Match suggested departments

As an institute member with Academic Registrar role
I want to connect pack suggestions to real institute departments
So that courses can have clear academic ownership.

Acceptance criteria

The user can match, create a Draft department, defer, or use an allowed not-applicable option.
MedCES identifies duplicate and inactive department choices.
Pack suggestions and local department IDs remain distinct and traceable.
A department mapping does not create a user permission.
Unresolved mandatory mappings appear in Setup Readiness.

Use case 3: Record programme authorities and intake

As an institute member with Academic Registrar role
I want to record the programme’s recognition, affiliation, and approved intake
So that Admissions and compliance use the correct authority context.

Acceptance criteria

The selected relationships apply to the same institute and relevant programme period.
Each approved-intake value records seats, applicability, authority, source, and effective dates.
Overlapping approved-intake records for the same authority and scope are blocked.
A missing mandatory authority relationship prevents activation and explains what is missing.

Use case 4: Create a local programme without a pack

As an institute member with Academic Registrar role
I want to create an approved local programme when no supported pack exists
So that the institute is not limited to pre-seeded programmes.

Acceptance criteria

The user enters the complete programme identity and source approval.
The new programme is marked as locally created.
A blank Draft curriculum version can be created for it.
The same validation, review, approval, and version rules apply as for pack-installed records.
Unsupported automatic requirement behaviour cannot be invented through setup.

Use case 5: Activate an institute programme

As an institute member with the required approval responsibility
I want to approve an institute programme
So that it can be used for curriculum and admission planning.

Acceptance criteria

Programme identity, authority requirements, effective dates, and required department mappings are complete.
The approver sees local changes made after pack installation.
The preparer cannot approve their own high-impact draft unless a configured exception is recorded.
Activation does not publish the curriculum or create a cohort.
Closure is prospective and does not remove historical admission or learner references.

Business rules

An institute programme belongs to exactly one institute.
A pack is a code-based template, not a shared runtime programme record.
Installation creates institute-owned copies with source-pack information.
A programme code is unique within its institute and effective period.
Pack installation never grants user access or creates faculty assignments.
One institute programme may have several curriculum versions, but only published versions can be assigned to cohorts.
Authority relationships remain outside the organisational LTREE and are linked to the institute programme.
Approved intake is versioned by effective period and source.
Published or historically used records are retired, not deleted.

Technical design

How the records relate

org.institute
  -> academic.institute_programme
       -> academic.programme_authority
       -> academic.programme_approved_intake
       -> academic.curriculum
            -> academic.curriculum_version

setup.pack_installation
  -> created institute programme, courses, and curriculum version

Conceptual schema

Record	Important fields
`academic.institute_programme`	institute, code, name, qualification, family, progression pattern, duration, internship relationship, coordinating responsibility, dates, status
`academic.programme_authority`	institute programme, authority relationship, role, identifier, validity, source
`academic.programme_approved_intake`	institute programme, seat count, admission-year range, authority relationship, source, status
`setup.pack_installation`	institute, programme, pack key/version, installation key, installed by/at, result status
`setup.pack_department_match`	installation, pack department key, institute department, action, reason, state
`setup.pack_item_origin`	created record type/id, pack key/version/item key, original hash, local change state, change policy

Pack keys are stored for source comparison. Institute academic records do not use them as operational foreign keys.

Process-layer responsibilities

The process layer:

validates pack integrity and application compatibility;
previews the exact records that installation will create;
creates institute records in one controlled, repeatable operation;
detects existing programme, course, department, and pack-installation conflicts;
checks authority and approved-intake applicability;
calculates setup gaps for Setup Readiness;
records source origin and local-change state.

It does not:

hard-code a particular institute’s departments or codes;
activate the programme without institute approval;
publish the curriculum created by installation;
move an existing cohort when a new pack is installed.

Success outcome

The institute has an approved, institute-owned programme with traceable authority information, safe pack history, and Draft academic records ready for detailed course and curriculum work.