Curriculum Versions and Pack Updates

Epic summary

The Curriculum Versions and Pack Updates workspace protects institute curricula when MedCES releases a new version of a programme pack.

A code deployment may make a new pack available. It never rewrites a published institute curriculum.

Installed pack version
  + institute's local changes
  + newly released pack version
  -> comparison
  -> proposed successor curriculum version
  -> institute review and approval

New institutes normally install the latest supported pack. Existing institutes choose when to review a pack update and whether it applies to future admission batches.

Before you start

The institute must have an existing programme and a recorded pack installation. A newer compatible pack must be available in the running MedCES release. Users reviewing the update need access to the current institute curriculum, its local changes, and the new pack’s source documents.

Actors and access

Access source	Access in this epic
Institute member with Academic Registrar role	Opens an update, prepares the successor Draft, and coordinates decisions
Institute member with Curriculum Committee role	Reviews academic additions, changes, removals, and conflicts
Department Admin, normally with HOD appointment	Reviews course and delivery changes affecting assigned departments
Institute member with Curriculum Approver role	Approves the successor version and its applicability
Platform Admin	Makes a tested pack version available but cannot apply it for the institute
Auditor role	Views the comparison, institute decisions, approvals, and affected future use

What can change

The workspace distinguishes a content update from a product feature.

Change	What MedCES needs
Competency text or source reference changes	New pack version
Course, stage, posting, or assessment definition is added	New pack version
An assessment outcome contract changes	New pack version
A phase transition, condition, threshold, or AND/OR structure changes	New pack version
A duration or other curriculum threshold changes	New pack version
A new calculation or requirement behaviour is introduced	Tested process-layer feature and new pack version
Institute adds a permitted local elective	Institute curriculum version; no pack release

A pack cannot claim that MedCES will automatically evaluate behaviour that the current process layer does not support.

What the user does

The workspace contains six screens:

1. Available Updates
2. Change Summary
3. Detailed Comparison
4. Conflict Decisions
5. Successor Version Setup
6. Impact Review and Approval

Screen 1: Available Updates

Field	Meaning
Institute programme	Programme that was created from the pack
Installed pack version	Version used to create the current institute records
Latest supported pack version	New version available in the application
Applicability	Admission batches or effective date stated by the source
Update type	Revision, corrigendum, source correction, or MedCES data correction
Process support	Whether all requirement behaviours are supported by this MedCES release
Review state	Not started, in review, deferred, applied to Draft, or completed

The user can start review, defer with a reason and review date, or mark the update not applicable where the source permits that decision.

Screen 2: Change Summary

MedCES groups differences into:

• items added by the new pack;
• pack items changed;
• pack items removed;
• unchanged pack items;
• institute items added locally;
• institute changes to earlier pack items;
• locked changes requiring action;
• items needing a new process-layer evaluator.

Counts link to the exact affected stages, courses, competencies, postings, assessment definitions, phase transitions, condition groups, and rules.

Screen 3: Detailed Comparison

The comparison shows three values side by side:

Earlier pack	Current institute value	New pack
What MedCES originally supplied	What the institute uses now	What the new release supplies

For each item, the screen shows:

• stable pack item key;
• field-level changes;
• source document and section;
• whether the institute changed the earlier value;
• change policy: locked, locally editable, or locally extendable;
• affected institute records and delivery mappings;
• proposed action and whether a decision is required.

Screen 4: Conflict Decisions

A conflict exists when the institute changed an earlier pack value and the new pack changes the same value, or when removal would affect an institute addition or mapping.

The user chooses an allowed action:

• accept the new pack value;
• keep the institute value where local editing is allowed;
• combine additions where extension is allowed;
• replace the local item and remap its relationships;
• defer the item with an approved reason;
• request product support for unsupported behaviour.

Every decision records the user, reason, source, and affected field. Locked regulatory changes cannot be rejected through ordinary local setup.

Screen 5: Successor Version Setup

Applying the reviewed changes creates a new Draft institute curriculum version.

Field	Required	What the user defines
Successor version name/code	Yes	Institute identity for the new version
Based on curriculum version	Yes	Current institute version being succeeded
New pack key/version	Yes	Source version being applied
Applicable admission batches	Yes	Future batches that may use the version
Effective date	Yes	Date from which it may be selected
Change summary	Yes	Plain explanation of important changes
Local additions carried forward	Selected	Institute items to keep in the successor
Delivery mappings carried forward	Selected	Mappings that remain valid after comparison

The process copies unchanged institute records, applies accepted pack changes, carries permitted local additions, and marks affected delivery mappings for reconfirmation.

Screen 6: Impact Review and Approval

Before submission, MedCES shows:

• future cohorts that could select the new version;
• existing cohorts that remain on the old version;
• changed courses, competencies, postings, assessment definitions, outcome contracts, phase transitions, and progression condition trees;
• department, facility, site, capacity, and role mappings needing review;
• requirements without supported evaluation;
• unresolved conflicts;
• applicability or authority inconsistencies.

The academic body approves and publishes the successor only after Curriculum Builder and Curriculum Delivery Setup validations pass.

Worked example: competency and posting update

Institute A installed mbbs-cbme-2024 version 1.1.0 and later added a local elective. MedCES release 3.4 contains pack version 1.2.0, which:

• corrects one competency description;
• adds one source-defined competency;
• changes a posting source reference without changing duration;
• introduces no new evaluator behaviour.

The comparison shows the local elective as an institute addition. The committee accepts the two pack changes, carries the elective forward, and confirms that the existing clinical-site mapping still satisfies the posting. MedCES creates CBME 2024 - Institute Version 2 as Draft.

The institute publishes Version 2 for the 2027 intake. The 2026 cohort remains pinned to Version 1.

Use case 1: Review an available pack update

As an institute member with Academic Registrar role
I want to see what changed in a released pack
So that the institute can make an informed decision.

Acceptance criteria

• The screen identifies installed, available, and application-compatible versions.
• Changes are grouped and linked to exact academic items and source references.
• Pack changes and institute local changes are shown separately.
• Starting review does not modify any institute academic record.
• Deferral records a reason and next review date.

Use case 2: Resolve a local-change conflict

As an institute member with Curriculum Committee role
I want to decide how a new pack value affects an institute change
So that valid local work is not silently lost.

Acceptance criteria

• Earlier pack, current institute, and new pack values are visible together.
• Only actions permitted by the pack change policy are offered.
• The user records a reason for keeping, combining, replacing, or deferring.
• Related competencies, requirements, and delivery mappings are listed before confirmation.
• No unresolved conflict can be applied to the successor Draft.

Use case 3: Create a successor curriculum version

As an institute member with Academic Registrar role
I want to apply reviewed changes to a new Draft version
So that the published curriculum remains unchanged.

Acceptance criteria

• The successor records its previous institute version and new pack version.
• Accepted changes, unchanged records, and permitted local additions are copied once.
• A repeated apply request does not create duplicate versions or items.
• Affected delivery mappings are marked for review rather than assumed valid.
• The earlier curriculum remains published and unchanged.

Use case 4: Introduce a new requirement behaviour

As an institute member with Curriculum Committee role
I want to know when a pack needs new product support
So that the institute does not rely on a rule MedCES cannot evaluate.

Acceptance criteria

• The pack manifest states the evaluator versions it requires.
• Installation or update is blocked when the running application lacks a mandatory evaluator.
• Advisory storage is allowed only when policy permits and the limitation is visible.
• Product support is implemented and tested before automatic evaluation is enabled.

Use case 5: Publish the successor for future selection

As an institute member with the required approval responsibility
I want to approve the updated curriculum for a defined intake
So that future cohorts use it without changing existing learners.

Acceptance criteria

• Curriculum and delivery validation pass with no unresolved mandatory gap.
• Applicability identifies the future admission batches that may select the version.
• Existing cohorts and learner enrolments remain on their pinned version.
• The approver sees the complete change and impact summary.
• Publication records the approval body, decision, source, and time.

Business rules

• A new pack version never changes institute records automatically.
• Starting or reviewing an update is read-only.
• Applying an update always creates a new Draft institute curriculum version.
• Stable pack item keys support comparison but are not operational foreign keys.
• Institute additions are carried forward only through an explicit decision.
• Pack-locked requirements cannot be weakened by a local conflict decision.
• Existing cohorts remain pinned to their current curriculum version.
• A published change to an assessment definition, outcome contract, phase transition, progression condition, threshold, or AND/OR structure always requires a successor curriculum version.
• Progression rules do not carry a separate business version outside the curriculum version.
• New evaluator behaviour requires tested process-layer support in the application release.
• Every comparison, decision, copied mapping, and approval is auditable.
• The earlier published version remains available for historical evaluation.
• Any request to move an existing cohort to another curriculum version belongs to Student and Cohort Management and is never executed from this workspace.

Technical design

How comparison works

setup.pack_item_origin.original_value_hash
  + current institute record
  + new pack item with same stable key
  -> field comparison
  -> change classification
  -> user decision when needed
  -> successor institute record

Conceptual schema

Record	Important fields
setup.pack_release	pack key/version, application compatibility, manifest hash, source, applicability, evaluator requirements
setup.pack_installation	institute, programme, installed pack version, installed at/by, result
setup.pack_item_origin	institute record, pack item key/version, original value hash, local change state, change policy
setup.pack_update_review	installation, from/to pack version, institute programme, state, started/deferred/completed by/at
setup.pack_change	review, item key, record type, change class, earlier/current/new values, conflict state, impact
setup.pack_change_decision	change, action, reason, source, decided by/at
academic.curriculum_version	institute curriculum, previous version, pack origin, applicability, dates, status

The pack release can be read from validated code assets and exposed through a read model. It need not be a mutable global academic catalogue.

Process-layer responsibilities

The process layer:

• validates pack manifests, stable keys, checksums, and evaluator compatibility;
• compares earlier pack, current institute record, and new pack values;
• classifies additions, changes, removals, institute edits, and conflicts;
• limits actions according to each item’s change policy;
• creates one complete successor Draft without rewriting the source version;
• carries forward approved local additions and still-valid mappings;
• marks affected delivery setup for reconfirmation;
• calculates cohort and operational impact;
• prevents accidental or repeated application.

It does not:

• apply a pack on deployment;
• decide institute academic policy;
• silently choose a conflict result;
• move cohorts or learner records automatically;
• evaluate an unsupported new requirement type.

Success outcome

The institute can adopt tested pack improvements without losing local decisions, changing published history, or moving existing cohorts unexpectedly.