Course Workspace and Academic Delivery

Epic summary

The Course Workspace and Academic Delivery epic is the day-to-day working area for one cohort course offering.

It is shared by faculty and students, but each sees the actions appropriate to their role and assignment. Access is derived from the offering, phase participation, learner-group membership, and faculty assignment. The institute does not enrol the same student into every course workspace by hand.

Cohort course offering
  -> released schedule and teaching plan
  -> faculty conducts a session
  -> actual delivery is recorded
  -> attendance is taken through the Attendance service
  -> students receive materials, announcements, and discussion access

MedCES provides the operational workspace needed by an Indian medical college. It is not intended to become a full learning-management or video-hosting platform.

This epic covers courses and their ordinary theory, practical, tutorial, and small-group teaching. Clinical-posting delivery uses its own posting workspace because its roster, unit, supervision, and daily work are different.

The course’s Logbook tab is a contextual view of records owned by Competency and Logbook. It can show requirements, teaching exposure, learner evidence, faculty review, and course-coordinator certification without copying those records into the course workspace.

Open Learner Logbook and Evidence →

Before you start

The following must already exist:

• an Active cohort phase plan;
• an Active cohort course offering;
• actual phase participants and required learner-group memberships;
• inherited curriculum delivery components and competencies;
• released timetable items for scheduled sessions;
• a Course Coordinator and eligible faculty assignments; and
• document-storage, notification, and discussion controls for the institute.

An offering may be visible before every future session has full academic detail. A session cannot be conducted until its audience, date, duration, and authorised faculty are known.

Actors and access

Access source	Access in this epic
Institute member with Course Coordinator role	Manages the offering workspace, future teaching schedule, materials, announcements, discussions, delivery coverage, and permitted corrections
Department Admin, normally with HOD appointment	Reviews department-owned course delivery and resolves coordinator or faculty issues
Assigned Faculty	Views assigned work, completes permitted session detail, conducts sessions, shares material, and participates in discussion
Substitute Faculty with valid assignment	Records actual delivery only through an authorised substitution or correction route
Institute member with Phase Coordinator role	Reviews delivery coverage and unresolved gaps across the phase
Institute member with Academic Registrar role	Reviews institute-level delivery and approves exceptional corrections where policy requires it
Student	Views the released schedule, materials, announcements, discussions, and own attendance for applicable courses and groups
Auditor role	Reads planned and actual delivery, changes, materials, communications, moderation, and history within scope

A Faculty role does not grant access to every course. The user must also have an effective course, department, session, or substitute assignment.

Workspace structure

The workspace contains:

1. Course Home
2. Schedule and Teaching Plan
3. Conduct Session
4. Materials
5. Announcements
6. Discussions
7. Learners and Groups
8. Delivery Coverage and Corrections

Screen 1: Course Home

The home screen gives a short operational view of the offering.

Faculty see:

• course, cohort, phase, and responsible department;
• inherited delivery-component requirements;
• next assigned sessions;
• sessions awaiting delivery reconciliation;
• planned, scheduled, conducted, cancelled, and replacement coverage;
• outstanding attendance actions;
• current announcements and discussions; and
• unresolved academic-detail or delivery issues.

Students see:

• the same course identity and coordinator;
• their next released sessions;
• recent schedule changes;
• materials released to their audience;
• announcements and discussions; and
• a link to their own attendance view.

Students do not see private faculty notes, other students’ attendance, hidden material, or internal readiness issues.

Screen 2: Schedule and Teaching Plan

This screen presents the offering’s Departmental Teaching Schedule alongside the current published timetable.

For each session it shows:

• delivery component;
• topic and title;
• linked competencies and learning objectives;
• full cohort or learner-group audience;
• planned date, time, duration, faculty, and facility;
• academic-detail state;
• publication state; and
• delivery state.

What the Course Coordinator may change

The Course Coordinator may update a future session’s topic, competencies, objectives, or planned faculty when the curriculum permits it. Every change is audited.

A date, time, duration, audience, or room change is a timetable change. It must go through the timetable revision route when the item has been published.

Required component types, hours, competencies, or curriculum rules cannot be changed here. They require a successor curriculum version.

Screen 3: Conduct Session

The faculty member opens a scheduled session and records what actually happened.

Field	Required	What is recorded
Planned session	Yes	Source course session and current timetable allocation
Delivery outcome	Yes	Conducted, Partially Conducted, Cancelled, or Rescheduled
Actual start and end	Yes when conducted	Actual teaching interval rather than assumed planned time
Actual faculty	Yes when conducted	Faculty who delivered, including authorised substitutes
Actual facility	Conditional	Place where teaching occurred if different or required
Actual topic	Yes when conducted	Topic actually covered
Competencies covered	Conditional	Applicable competencies from the same curriculum version
Objectives covered	Conditional	Planned or amended objectives actually addressed
Deviation reason	Conditional	Required when plan and delivery differ materially
Replacement required	Conditional	Whether cancelled or partial work must be rescheduled
Faculty notes	No	Operational teaching note; not a student assessment
Evidence or material	No	Permitted attachment or link supporting the delivery record

Planned and actual faculty are intentionally separate. A substitute teacher must not overwrite the original plan as though no substitution occurred.

After saving the delivery record, the faculty member may open attendance for the applicable occurrence. Attendance marks remain owned by the Attendance epic.

Screen 4: Materials

Faculty can share lightweight course material without recreating a full learning-management system.

Field	Required	Meaning
Title	Yes	Student-facing material name
Description	No	Short explanation of its purpose
Material type	Yes	File, link, reading, image, presentation, or another controlled type
File or link	Yes	Stored object or approved external location
Course or session scope	Yes	Whole offering or one named session
Audience	Yes	Full offering or selected applicable learner groups
Visible from and until	Yes/No	Release window
Download permission	Yes	Whether the audience may download where supported
Version note	Conditional	What changed when material is replaced

A replacement creates a new material version. Withdrawal hides future access but retains the earlier release and audit record.

Patient-identifiable information must never be uploaded as teaching material. Institute file-type, size, security, and retention rules apply.

Screen 5: Announcements

The Course Coordinator and authorised faculty may publish a notice to the whole offering or selected groups.

An announcement records:

• title and message;
• course, group, or session scope;
• visible-from and expiry time;
• author and author assignment;
• attachment or link where permitted;
• whether acknowledgement is requested; and
• replacement, withdrawal, and notification history.

An announcement may explain a timetable change, but it does not itself change the timetable.

Screen 6: Discussions

Discussions support structured questions and course conversation.

The author defines:

• discussion title and prompt;
• whole-course or group audience;
• optional session or topic relationship;
• open and close dates;
• who may start threads and reply;
• attachment permission; and
• moderation and archive state.

Students and faculty can post and reply within their permitted audience. Moderators may hide an unsafe post with a reason; the original remains in the audit record.

Clinical cases must be anonymised. The interface warns users not to enter patient names, identifiers, photographs, or other identifiable clinical information.

Screen 7: Learners and Groups

This screen is a read-only operational roster derived from the phase plan and group memberships.

It shows:

• active learners covered by the offering;
• their applicable practical, tutorial, or other groups;
• effective membership dates;
• authorised individual exceptions; and
• workspace access state.

The Course Coordinator can report a roster problem but cannot create a programme enrolment, move a student between cohorts, or rewrite learner-group history from this workspace.

Students cannot browse private information about other learners. A discussion member list, where shown, exposes only the minimum allowed profile information.

Screen 8: Delivery Coverage and Corrections

Coverage compares the inherited requirement with what has been scheduled and conducted for every applicable audience.

Practical requirement: 30 hours per learner group

Group A: 30 scheduled / 27 conducted / 3 replacement required
Group B: 30 scheduled / 30 conducted / complete

The screen distinguishes:

• planned coverage;
• published scheduled coverage;
• conducted coverage;
• cancelled or partially conducted time;
• replacement work required and scheduled;
• audience-specific shortages; and
• actual topic or competency coverage.

A correction to a conducted session records the earlier value, new value, reason, requester, approver where required, and time. A correction cannot silently change finalised attendance.

Use case 1: Open the applicable course workspace

As a Faculty member or Student
I want to open the course offering that applies to me
So that I can see the correct schedule, information, and actions.

Acceptance criteria

• Access is derived from current phase, group, and faculty assignments.
• Manual per-course student enrolment is not required.
• A student sees only released information for an applicable audience.
• A faculty member sees authoring actions only for an effective assignment.
• Ended access remains in history but no longer permits new actions.

Use case 2: Maintain the future teaching plan

As a Course Coordinator
I want to complete or amend future session detail
So that faculty and students understand what will be taught.

Acceptance criteria

• Topics and competencies remain within the offering’s curriculum version.
• Every change retains the earlier value and actor.
• Published date, time, duration, audience, or room changes use timetable revision.
• Curriculum-owned requirements remain read-only.
• An academically incomplete future session is clearly marked.

Use case 3: Record actual teaching

As an assigned Faculty member
I want to record what happened in a session
So that course coverage reflects actual delivery rather than the timetable alone.

Acceptance criteria

• The record references one planned session or an authorised exceptional occurrence.
• Actual time, faculty, topic, and outcome are stored separately from the plan.
• A material difference requires a reason.
• Cancellation or partial delivery can create a replacement need.
• Repeated submission does not create two delivery records for the same occurrence.

Use case 4: Share course material

As an authorised Faculty member
I want to release material to an applicable audience
So that students can find course resources in the same workspace.

Acceptance criteria

• The material has a clear course or session scope and audience.
• Visibility follows the release window.
• Replacements retain version history.
• Withdrawn material is no longer available to students but remains auditable.
• File security and patient-privacy checks are applied.

Use case 5: Communicate with the course

As a Course Coordinator, Faculty member, or Student
I want to use announcements and permitted discussions
So that operational questions and course communication are not scattered across informal channels.

Acceptance criteria

• Announcement and discussion permissions are different and explicit.
• Every message has an applicable course or group audience.
• Notifications do not grant access to the underlying content.
• Moderation retains the original post and reason.
• Patient-identifiable content is prohibited and reportable.

Use case 6: Reconcile delivery coverage

As a Course Coordinator
I want to compare required, scheduled, and conducted work
So that missing teaching can be recovered before the phase closes.

Acceptance criteria

• Coverage is calculated separately by component and audience.
• A cancelled session does not count as conducted.
• Partial delivery contributes only the accepted actual amount.
• Replacement sessions retain the relationship to the original gap.
• Course completion is blocked while mandatory delivery gaps remain unless an authorised exception exists.

Business rules

1. The course workspace is a view over one cohort course offering, not a new course identity.
2. Student access comes from authoritative phase participation and group membership.
3. Planned delivery, actual delivery, and attendance are separate records.
4. A timetable entry does not prove that teaching occurred.
5. Actual faculty never overwrites planned faculty.
6. Future timetable changes follow publication controls.
7. Curriculum requirements cannot be changed inside an active offering.
8. Materials and discussions must not contain identifiable patient information.
9. Clinical-posting delivery and assessment operations are outside this workspace.

Exception paths

• Substitute faculty teaches: validate an eligible assignment or approval and record both planned and actual faculty.
• Session is cancelled: record the outcome and reason, void any unfinalised attendance occurrence, and create a replacement need where required.
• Session is partially conducted: record accepted actual duration and remaining coverage.
• Wrong topic or time was recorded: use a controlled delivery correction; never overwrite history.
• Roster is incorrect: send the issue to phase or learner-group management rather than editing membership here.
• Patient information is reported: restrict access to the item, preserve evidence, and route it through institute privacy and moderation policy.

Conceptual schema

Record	Important fields
academic.cohort_course_offering	phase plan, curriculum course placement, coordinator, delivery window, status
academic.course_session	offering component, topic, objectives, audience, planned duration, academic-detail state
academic.course_delivery_record	session, outcome, actual interval, actual facility, actual topic, deviation reason, replacement state
academic.course_delivery_faculty	delivery record, faculty assignment, contribution type, actual duration
academic.course_delivery_competency	delivery record, curriculum competency, coverage state
academic.course_delivery_correction	delivery record, requested change, reason, decision, earlier and new values
academic.course_material	offering, session scope, audience, title, type, current version, visibility state
academic.course_material_version	material, file or link, version number, uploader, release window, checksum
academic.course_announcement	offering, audience, message, release window, author, state
academic.course_discussion	offering, group or session scope, prompt, permissions, open interval, moderation state
academic.course_discussion_post	discussion, parent post, author, content, attachment, moderation state
academic.course_workspace_event	offering, action, actor, assignment, affected record, time

The workspace does not need a second enrolment table. Its learner access is resolved from academic.phase_plan_participant, academic.learner_group_membership, and the session audience.

Process-layer responsibilities

The process layer must:

• derive faculty and student access from current assignments and effective dates;
• return only material, announcements, discussions, and sessions for the user’s audience;
• keep planned session values separate from actual delivery;
• validate actual faculty, facility, time, topic, and competencies;
• create one delivery record per occurrence and make resubmission safe;
• calculate delivered coverage by component, learner group, and learner applicability;
• create and track replacement needs for cancelled or partial delivery;
• route published timetable changes through the timetable revision service;
• connect attendance without storing attendance marks in delivery records;
• version materials and enforce file, privacy, retention, and visibility rules;
• enforce discussion audience and moderation rules;
• preserve every material change and correction; and
• prevent course-workspace actions from changing curriculum, enrolment, group, or assessment records.

Out of scope

This epic does not include:

• SCORM packages or rich online-course authoring;
• video hosting or virtual-classroom infrastructure;
• assignments, plagiarism checking, quizzes, examinations, or a gradebook;
• programme enrolment or learner-group management;
• clinical-posting scheduling or the daily records owned by Clinical Posting Workspace and Delivery;
• attendance-policy definition or attendance calculations; or
• student progression decisions.