Course Offerings and Course Scheduling

Epic summary

The Course Offerings and Course Scheduling workspace turns one course placement from the curriculum into actual teaching for one cohort phase.

The course offering does not ask the user to redefine the course. It inherits the approved curriculum requirements and adds only the information needed to operate them for this cohort.

Institute course
  -> Course placement in a published curriculum version
      -> Required delivery components
          -> Cohort course offering
              -> Course sessions
                  -> Timetable allocations

For example, the curriculum may require Anatomy in Phase I with lectures, dissection, histology practicals, and tutorials. The Anatomy offering identifies the actual cohort, learner groups, coordinator, delivery dates, eligible faculty and facilities, and the dated sessions through which those requirements will be delivered.

This epic covers course teaching only. It does not create clinical-posting rotations or assessment events.

Before you start

The following must already exist:

an active cohort with a published curriculum version;
a dated cohort phase plan for the applicable curriculum stage;
the curriculum course placement and its delivery components;
the responsible and contributing department mappings;
the learner-group types required by the curriculum;
actual learner groups where a component is group-based;
eligible facility capabilities and capacity rules;
an applicable academic calendar and period templates; and
users assigned to the required academic and scheduling roles.

A Draft offering can be created while some learner groups or named assignments are incomplete. It cannot become Ready for Scheduling until every mandatory dependency used by its components is available.

Actors and access

Access source	Access in this epic
Institute member with Academic Registrar role	Oversees phase-level offering readiness and resolves institute-wide academic planning issues
Institute member with Phase Coordinator role	Reviews all offerings in the assigned phase plan and coordinates their preparation
Department Admin, normally with HOD appointment	Confirms department capacity, coordinator, faculty pool, and teaching-schedule readiness
Institute member with Course Coordinator role	Prepares the assigned offering, learner-group mapping, sessions, topics, competencies, objectives, and planned faculty
Institute member with Timetable Coordinator role	Places course sessions manually, runs automatic scheduling, manages locks, and resolves clashes
Facilities Officer role	Confirms facility capability, capacity, and availability; does not author course content
Faculty	Views assigned sessions and completes permitted teaching details for those sessions
Student	Views only sessions released for the student’s cohort or assigned learning group
Auditor role	Reads inherited requirements, operational choices, scheduling runs, changes, and history

Institute Admin and Tenant Admin can see summaries permitted by their scope. They do not receive Course Coordinator or Timetable Coordinator capabilities merely because they are administrators.

Offering lifecycle

Draft
  -> Ready for Scheduling
  -> Partially Scheduled
  -> Fully Scheduled
  -> Active
  -> Completed

An offering may be Cancelled only through an authorised action with impact review. Timetable publication is a separate control: a Fully Scheduled offering may still be part of a Draft master timetable.

Dates do not automatically move the offering between lifecycle states.

Workspace structure

The workspace contains:

Phase Course List
Offering Details
Inherited Delivery Components
Learner Groups and Resources
Departmental Teaching Schedule
Manual Course Scheduler
Automatic Scheduling
Coverage, Conflicts, and History

Screen 1: Phase Course List

When a phase plan is created, MedCES prepares one Draft offering for every mandatory course placement in that phase. Repeating the action must not create duplicates.

Elective, optional, or remedial offerings are created only after the applicable learner or academic decision exists.

Each course row shows:

course code and name;
responsible department;
curriculum component summary;
required learner hours or sessions;
course coordinator;
learner-group readiness;
planned and scheduled coverage;
conflict count; and
offering status and next action.

The Phase Coordinator can filter by department, component type, coordinator, readiness, status, or unresolved issue.

Screen 2: Offering Details

The top of the screen clearly separates inherited curriculum information from offering-specific information.

Inherited information

Field	Meaning
Institute course	Course identity from the institute catalogue
Curriculum version	Exact version pinned to the cohort
Curriculum stage	Phase in which the placement appears
Placement status	Mandatory, elective, optional, or remedial
Responsible department	Approved curriculum delivery owner
Delivery components	Required lecture, practical, tutorial, small-group, or other components
Competencies	Competencies related to the course placement and its components
Source	Pack, regulation, university instruction, or approved institute decision

These values are read-only. A required academic change must be made through a successor curriculum version rather than an offering override.

Offering-specific fields

Field	Required	What the user defines
Cohort phase plan	Inherited	Dated phase and cohort receiving the course
Planned start and end dates	Yes	Delivery window inside the phase-plan dates
Course Coordinator	Yes	Eligible current assignment responsible for the offering
Department confirmation	Yes before scheduling	Confirmation that the department can deliver the offering
Scheduling priority	No	Operational priority used as a preference, not permission to break a hard rule
Preferred or unavailable windows	No	Course-specific preferences inside the approved calendar
Operational notes	No	Plain-language notes that do not change curriculum requirements

The offering cannot change required hours, component types, audience modes, competencies, or source-defined rules.

Screen 3: Inherited Delivery Components

Each component appears as an inherited requirement with an operational readiness section.

Example:

Anatomy Lecture
Required: 40 hours per learner
Audience: Full cohort
Default duration: 1 hour
Facility capability: Lecture hall

Anatomy Dissection
Required: 60 hours per learner
Audience: Each practical group separately
Default duration: 3 hours
Facility capability: Dissection hall

For each component, the system shows:

required amount and unit;
default session duration;
audience mode and required group type;
eligible department and faculty pool;
required facility capability;
group-size and parallel-delivery limits;
required sequence or distribution rule;
planned, scheduled, delivered, and remaining coverage; and
the exact source of the requirement.

The user may plan fewer parallel groups than the institute can support. The user cannot exceed a curriculum, safety, faculty, or facility limit without an authorised exception route.

Screen 4: Learner Groups and Resources

Full-cohort components automatically use the active learners assigned to the phase plan.

For group-based components, the user connects the required group type to actual learner groups. For example:

Curriculum audience: Practical groups
Actual groups:        Practical A, Practical B, Practical C, Practical D

Field	Required	What the user defines
Delivery component	Inherited	Component whose operational audience is being prepared
Actual learner groups	Conditional	Active phase-plan groups matching the required group type
Eligible faculty pool	Conditional	Faculty who satisfy department, designation, association, and assignment rules
Preferred named faculty	No	Planned teacher where known; not the permanent owner of every future session
Eligible facilities	Conditional	Active locations providing the required capability and capacity
Planned parallel use	Conditional	Number of groups intended to run together, within validated limits
Effective dates	Yes	Period for which the operational mapping applies

Every active learner must be covered by the full-cohort audience or exactly one applicable group unless an authorised individual exception is recorded.

Screen 5: Departmental Teaching Schedule

The Departmental Teaching Schedule is a workspace inside the offering. It is not another curriculum and it is not a compulsory document that must be finished before the first scheduling run.

The department may work in either order.

Topic-first

The department prepares course sessions with topics and then sends them for scheduling.

Timetable-first

The Timetable Coordinator allocates course periods from the inherited component requirements. The department then completes the academic detail for those session shells.

Course-session fields

Field	Required	What the user defines
Delivery component	Yes	Inherited lecture, practical, tutorial, or other component
Session title or topic	Required before teaching-schedule confirmation	Topic to be delivered in this occurrence
Duration	Yes	Supported duration that contributes to component coverage
Audience	Yes	Full cohort or actual learner group resolved from the component
Teaching method	Inherited/Yes	Method permitted for this component
Competencies	Conditional	Competencies from the same curriculum version covered by the session
Specific learning objectives	Conditional	Objectives required by institute policy or the applicable teaching schedule
Sequence	No	Required order where one session depends on another
Planned faculty	No/Conditional	Eligible named faculty member or faculty pool
Facility capability	Inherited	Capability required before an actual location is selected
Department note	No	Preparation or delivery instruction for the session

The user may add sessions individually, copy an approved department pattern, or create session shells from required hours and the default duration.

Creating session shells does not invent topics. Empty shells are visibly marked Academic Detail Pending until the department completes them.

Screen 6: Manual Course Scheduler

The manual scheduler shows:

the phase calendar and available periods;
unscheduled course sessions;
learner groups;
faculty and faculty-pool availability;
suitable facilities and capacity;
existing locked academic activities; and
real-time conflicts and warnings.

The Timetable Coordinator drags a course session into a date and period or opens a scheduling form.

Field	Required	Meaning
Course session	Yes	Session or session shell being allocated
Date	Yes	Working date inside the offering and phase-plan interval
Start and end time	Yes	Valid period or permitted custom interval
Audience	Inherited	Full cohort or assigned learner group
Facility	Conditional	Active suitable location with enough capacity
Planned faculty	Conditional	Eligible and available faculty member where a named assignment is required
Lock state	Yes	Unlocked, User Locked, or Authority Locked
Scheduling note	Conditional	Required for a warning override or unusual allocation

Hard conflicts prevent saving. A warning may be accepted only where policy allows it and the user records a reason.

Screen 7: Automatic Scheduling

Automatic scheduling uses the same sessions, resources, constraints, and locks as the manual interface.

The user selects:

offerings or components to include;
date range;
sessions that must remain locked;
permitted facilities and faculty pools;
hard constraints that apply; and
preferences such as spread, preferred periods, or reduced learner gaps.

The scheduler must always enforce:

phase and offering dates;
working days, holidays, and protected periods;
learner-group availability;
named-faculty availability where required;
facility capability and capacity;
session duration;
source-defined sequence;
maximum concurrent groups; and
all authority-locked timetable entries.

It returns:

proposed allocations;
unscheduled sessions with a plain reason;
curriculum coverage after the proposal;
faculty, group, and facility warnings; and
the preferences it could not satisfy.

The result is always a proposal. The user reviews and accepts selected allocations. The automatic scheduler never publishes the timetable.

If the user runs it again, accepted locked allocations remain in place unless the user is authorised to unlock them.

Screen 8: Coverage, Conflicts, and History

Coverage is shown separately for each component and audience.

For a full-cohort lecture:

Required per learner: 40 hours
Scheduled:            40 hours
Coverage:             Complete

For a practical delivered to four groups:

Required per learner: 30 hours
Group A scheduled:    30 hours
Group B scheduled:    30 hours
Group C scheduled:    28 hours
Group D scheduled:    30 hours
Coverage:             Incomplete — Group C is short by 2 hours

The screen also shows:

unscheduled or partially scheduled sessions;
double-booked learners, faculty, or facilities;
facility-capability and capacity failures;
sessions outside the offering or phase dates;
missing topics, competencies, objectives, or faculty where required;
curriculum sequence and distribution warnings;
accepted warning reasons;
department confirmations; and
a read-only history of changes and scheduling runs.

Use case 1: Prepare required course offerings

As a Phase Coordinator
I want to prepare the courses required for the phase plan
So that every curriculum course has one visible operational owner and readiness state.

Acceptance criteria

One Draft offering is created for each mandatory course placement in the phase.
Repeating preparation returns the same offerings rather than creating duplicates.
Every offering points to the phase plan’s exact curriculum version and stage.
Elective, optional, and remedial offerings require their own supported reason.
Missing groups, coordinator assignments, facilities, or department confirmation are shown as named readiness gaps.

Use case 2: Complete offering-specific setup

As a Course Coordinator
I want to complete the operational details of my assigned offering
So that its inherited requirements can be scheduled for the cohort.

Acceptance criteria

Curriculum requirements are visible but cannot be edited from the offering.
Offering dates remain inside the phase-plan dates.
The coordinator is eligible and effective for the offering period.
Full-cohort and group-based components resolve their correct audiences.
Selected resources satisfy department, capability, capacity, and validity rules.
The offering becomes Ready for Scheduling only when every mandatory component is operationally ready.

Use case 3: Prepare course sessions

As a Course Coordinator
I want to divide the inherited delivery requirement into course sessions
So that topics can be assigned and the required teaching can be placed on the timetable.

Acceptance criteria

Every session references one inherited delivery component.
Group-based requirements create coverage for every actual learner group.
Session duration contributes to the correct component and audience total.
The user may prepare topics before scheduling or complete them after periods are allocated.
A session shell without a topic remains clearly marked Academic Detail Pending.
Only competencies from the cohort’s pinned curriculum version can be linked.

Use case 4: Schedule course sessions manually

As a Timetable Coordinator
I want to place course sessions into available dates and periods
So that the institute can control important allocations directly.

Acceptance criteria

Only valid dates and time intervals can be selected.
The system prevents learner-group, named-faculty, facility, capacity, and protected-period conflicts.
The scheduled audience cannot differ from the component and offering group mapping.
Suitable rooms are filtered by capability, capacity, validity, and availability.
The user may lock an accepted allocation within their authority.
Every warning override records the user, reason, time, and rule involved.

Use case 5: Generate a course-scheduling proposal

As a Timetable Coordinator
I want to automatically place eligible unscheduled course sessions
So that I can prepare a workable schedule without placing every session by hand.

Acceptance criteria

The automatic scheduler reads the same facts and rules as the manual interface.
Locked allocations are not moved.
Hard constraints are never traded for a better preference score.
Every unscheduled session has a plain-language reason.
The user can accept all, some, or none of the proposed allocations.
Accepting a proposal changes only Draft timetable allocations and records the scheduling run.
No proposal is published automatically.

Use case 6: Complete the departmental teaching schedule

As a Course Coordinator
I want to complete the topic-wise academic detail for scheduled course sessions
So that the department and learners know what will be taught in each period.

Acceptance criteria

Every session required by institute policy has a topic and supported teaching method.
Required competencies and specific learning objectives are connected to the correct session.
Planned faculty are eligible for the date and department relationship where a named assignment is required.
Topic entry does not change the scheduled duration, audience, room, or date without an authorised scheduling change.
The department can see remaining academic-detail gaps before confirmation.
Earlier values remain available in history after a correction.

Use case 7: Review course coverage and submit it for timetable review

As a Phase Coordinator
I want to review coverage and unresolved conflicts
So that only a complete and workable course schedule enters the master-timetable review.

Acceptance criteria

Required, planned, scheduled, and remaining coverage is shown for every component and learner group.
Group-delivery hours are not incorrectly compared with per-learner curriculum hours.
The screen identifies the exact session, group, faculty, facility, or rule causing a gap.
Missing required academic detail is shown separately from a scheduling conflict.
Submission is blocked while a hard conflict or mandatory coverage gap remains.
Submission does not itself publish the timetable.

Important business rules

There is one active course offering per curriculum course placement and cohort phase plan.
A course offering never changes its inherited curriculum requirements.
One offering may contain both full-cohort and group-based delivery components.
Every group in an Each Group Separately component must receive the required learner coverage.
Parallel delivery changes resource use and calendar time; it does not reduce what each learner must receive.
A planned faculty member and the faculty member who actually teaches are separate facts.
Practical teaching sessions are ordinary course sessions. Practical assessments are not created here.
Clinical-posting rotations and dated posting blocks remain separate from course sessions.
The automatic and manual schedulers use the same validation service.
An automatic result is a proposal and never a publication decision.
Locked and published records are not silently rewritten.

Conceptual schema

Record	Important fields
`academic.cohort_course_offering`	tenant, institute, phase plan, curriculum course placement, dates, coordinator assignment, department confirmation, source, status
`academic.course_offering_component_plan`	offering, curriculum delivery component, operational dates, readiness, resource preference, exception reference
`academic.course_offering_group`	component plan, learner group, validity, status
`academic.course_session`	offering, delivery component, title/topic, duration, teaching method, academic-detail state, sequence, status
`academic.course_session_audience`	session, audience type, cohort or learner group, inclusion/exclusion reason
`academic.course_session_competency`	session, curriculum competency, coverage type
`academic.course_session_faculty_plan`	session, named faculty or eligible pool, role, confirmation
`academic.timetable_allocation`	session, date, start/end, facility, lock state, allocation state, source
`academic.schedule_run`	scope, input snapshot, calendar, constraints, preferences, algorithm version, status, summary
`academic.schedule_proposal_item`	run, session, proposed date/time/facility/faculty, result, warning or unscheduled reason
`academic.course_offering_event`	offering, event type, earlier/new state, actor, reason, recorded at

Process-layer responsibilities

The process layer:

generates mandatory Draft offerings exactly once;
verifies curriculum, cohort, phase, department, and date compatibility;
reads curriculum requirements without copying them into editable offering fields;
resolves actual learner groups and checks complete, non-duplicated learner coverage;
expands full-cohort and group-based components into correct session and coverage requirements;
supports session-first and timetable-first planning;
calculates required, planned, scheduled, delivered, and remaining coverage by component and audience;
resolves eligible faculty and facilities from effective-dated Setup records;
detects group, faculty, facility, date, capability, capacity, sequence, and protected-period conflicts;
applies the same hard rules to manual and automatic scheduling;
retains user and authority locks across scheduling runs;
explains every validation failure and unscheduled result in plain language;
records proposal acceptance and all material changes; and
prevents this workspace from creating assessment or clinical-posting records.

Success outcome

Every required course in the cohort phase has one accountable offering, complete learner coverage, a usable department teaching schedule, and conflict-free course-session allocations ready for master-timetable review.