Course Catalogue

Epic summary

The Course Catalogue stores the stable academic courses used by an institute.

A course is owned by the institute, not by MedCES globally. It has one lead department and may have several contributing departments.

Institute course: Anatomy
  -> Lead department: Anatomy
  -> Contributing departments: Radiodiagnosis, Surgery

The course record says what Anatomy is inside the institute and who is responsible for it. The Curriculum Builder later decides where Anatomy appears in a curriculum version, which competencies are taught, how many hours are required, and how it is assessed.

This separation allows the institute course to remain stable while its use changes between curriculum versions.

Before you start

The institute and relevant departments must exist. If the course came from a programme pack, the pack installation and institute programme must already exist. A locally created course may be prepared before it is added to a curriculum.

Actors and access

Access source	Access in this epic
Institute member with Academic Registrar role	Reviews pack-created courses and creates local course drafts
Department Admin, normally with HOD appointment	Confirms lead or contributing responsibility for assigned departments
Institute member with Curriculum Committee role	Reviews academic classification and cross-department delivery
Institute member with Course Approver role	Approves a new course or material department change
Auditor role	Views course history, department decisions, sources, and curriculum usage

Course versus curriculum course

Record	What it answers	Example
Institute course	What course does this institute maintain?	Anatomy
Course-department relationship	Who owns and contributes to it?	Anatomy leads; Surgery contributes
Curriculum course	How is it used in this curriculum version?	Anatomy is mandatory in Phase I
Course competency	What must be learned in that curriculum?	Demonstrate anatomical knowledge for a named competency
Delivery setup	Which departments, eligible roles, rooms, and sites can deliver it?	Anatomy department and dissection hall

What the user does

The workspace contains five screens:

Course List
Course Details
Department Responsibilities
Academic Classification
Review and Usage

Screen 1: Course List

The list shows institute courses regardless of which programme currently uses them.

Users can filter by:

active, Draft, or archived state;
programme pack source;
lead or contributing department;
subject area and course type;
curriculum versions using the course;
pack-created or locally created origin.

The list highlights courses with no lead department, duplicate codes, unpublished changes, or a pending pack update.

Screen 2: Course Details

Field	Required	What the user defines
Course code	Yes	Stable code unique within the institute, such as `ANAT`
Course name	Yes	Formal name, such as `Anatomy`
Short name	No	Name used in compact displays
Course type	Yes	Subject, discipline, module, longitudinal course, elective, skill course, or another controlled type
Academic level	Conditional	Undergraduate, postgraduate, doctoral, or shared
Description	Yes	Plain explanation of the course’s scope
Effective dates	Yes/No	Date from which the course may be used and optional retirement date
Source	Yes	Pack source or local approval/source document
Status	Yes	Draft, Under Review, Approved, Published, or Archived

A course name may be shared by several curriculum versions. Its curriculum-specific hours, stages, requirements, and assessments are not entered here.

Screen 3: Department Responsibilities

The user adds department relationships to the course.

Field	Required	What the user defines
Department	Yes	Active department inside the same institute
Responsibility	Yes	Lead, contributing, assessment support, clinical delivery, or another controlled role
Effective dates	Yes/No	Period during which the responsibility applies
Contribution note	Conditional	Plain description of the department’s responsibility
Approval state	Yes	Draft, confirmed by department, or approved

Exactly one lead relationship must apply on any date when the course is published. More than one department may contribute.

A department relationship does not select a named faculty member and does not grant access. Standing academic assignments belong to Faculty Academic Associations and Curriculum Delivery Setup.

Screen 4: Academic Classification

This screen supplies stable search and reporting information without placing the course into a curriculum.

Field	Required	What the user defines
Subject/discipline category	Yes	Controlled academic classification
Clinical or non-clinical	Yes	Broad delivery classification
Delivery forms supported	No	Lecture, practical, laboratory, clinical, field, self-directed, or mixed
External codes	No	University, regulator, or reporting codes with validity
Shared-course flag	Yes	Whether more than one institute programme may use the course
Search terms	No	Approved aliases used to find the course

These values help users find and report the course. They do not create teaching-hour, delivery-component, or progression requirements. Those requirements are defined when the course is placed in a curriculum version.

Screen 5: Review and Usage

Before approval, the user sees:

the lead and contributing departments;
source-pack values and institute changes;
curriculum versions that use the course;
unresolved department confirmations;
other institute courses with a similar code, name, or external code;
the impact of changing or archiving the course.

Worked example: Anatomy

The MBBS pack creates a Draft course with:

Code: ANAT
Name: Anatomy
Type: Discipline
Pack source: mbbs-cbme-2024 / course.anatomy

The Academic Registrar:

confirms the local code and name;
assigns the Department of Anatomy as lead;
adds Radiodiagnosis as a contributing department for imaging integration;
publishes the course after both responsibilities are reviewed.

The course still has no Phase I hours or competency list. In Curriculum Builder, the user adds this published Anatomy course to MBBS CBME 2024, assigns it to Phase I, and attaches the applicable competencies and requirements.

Use case 1: Review a pack-created course

As an institute member with Academic Registrar role
I want to review a course created by pack installation
So that its identity matches the institute’s academic structure.

Acceptance criteria

The screen shows the original pack value and any local change side by side.
The user can change only fields allowed by the pack’s change policy.
The course remains institute-owned after review.
Missing lead-department mapping prevents publication and states the exact problem.
Reviewing a course does not place it into every curriculum automatically.

Use case 2: Create a local course

As an institute member with Academic Registrar role
I want to add an institute-approved course not supplied by a pack
So that local electives and academic requirements can be represented.

Acceptance criteria

Code, name, type, description, source approval, and effective date are captured.
The course is marked as locally created.
Duplicate code and likely duplicate-name warnings are shown before submission.
A lead department is required before publication.
The course is not added to a curriculum until a curriculum editor selects it.

Use case 3: Assign lead and contributing departments

As a Department Admin with HOD appointment
I want to confirm my department’s responsibility for a course
So that academic ownership and contribution are clear.

Acceptance criteria

Exactly one effective lead department exists for a published course.
Several contributing departments may be recorded with different responsibilities.
All departments belong to the same institute as the course.
Date ranges cannot create two simultaneous lead departments.
Changing the lead department requires impact review and approval.

Use case 4: Merge a duplicate Draft course

As an institute member with Academic Registrar role
I want to resolve duplicate Draft courses
So that curricula use one stable course identity.

Acceptance criteria

MedCES shows field, department, and curriculum-usage differences.
The user selects the surviving course and confirms how relationships will move.
Published or historically used courses are not physically merged through this Draft-only action.
The merge records both original identities and the authorised decision.

Use case 5: Retire a course

As an institute member with Academic Registrar role
I want to stop a course from being selected for new curriculum versions
So that old curricula remain correct while future use is prevented.

Acceptance criteria

The impact view lists every Draft, published, and historical curriculum version using the course.
Retirement uses an effective date and reason.
Existing published curricula and cohort snapshots continue to resolve the course.
A replacement course can be recorded where applicable.

Business rules

Every course belongs to one institute.
A published course has exactly one effective lead department.
A course may have any number of contributing departments.
Department responsibility and user permission are separate relationships.
Curriculum-specific stages, hours, competencies, postings, assessments, and progression rules do not belong on the course record.
A course can be used by several curriculum versions and institute programmes where permitted.
Pack-created and locally created courses follow the same publication rules.
A course referenced by a published curriculum or learner history is archived, not deleted.

Technical design

How the records relate

org.institute
  -> academic.institute_course
       -> academic.course_department
       -> academic.course_external_code

academic.institute_course
  <- academic.curriculum_course_placement
       -> academic.curriculum_version

Conceptual schema

Record	Important fields
`academic.institute_course`	institute, code, name, short name, type, level, description, classification, dates, origin, status
`academic.course_department`	course, department, responsibility type, contribution note, valid from/to, confirmation state
`academic.course_external_code`	course, authority, code system, code, validity, source
`academic.course_alias`	course, alias, language, usage, status
`academic.curriculum_course_placement`	curriculum version, institute course, stage, sequence, mandatory status, curriculum-specific values

The database enforces one active LEAD department relationship per course and applicable date. Service validation provides a clearer error before the database constraint is reached.

Process-layer responsibilities

The process layer:

checks course-code uniqueness within the institute;
detects likely duplicate names and external codes;
validates one lead and many contributing department relationships;
confirms that all departments are inside the same institute;
shows pack-origin differences and allowed local changes;
lists curriculum usage before ownership change or retirement;
preserves historical resolution after archival.

It does not:

decide which phase uses the course;
assign teaching hours, competencies, or assessments;
allocate faculty, rooms, or timetable periods;
infer system access from course ownership.

Success outcome

The institute has a clear, non-duplicated course catalogue with real departmental responsibility and a stable foundation for every curriculum version.