Student Record and Programme Enrolment

Epic summary

The Student Record and Programme Enrolment workspace receives a joined candidate from Admissions and creates the records needed for the student’s academic life.

The Student Section Officer performs one enrolment action:

Approved and joined candidate
  -> Match or create person
  -> Create or link student record
  -> Create programme enrolment
  -> Create cohort membership
  -> Issue student number

The officer does not separately select the programme, curriculum, cohort, or student-number format. These values come from the approved admission, planned cohort, and pinned identifier policy.

Why programme enrolment and cohort membership are separate records

The user completes one workflow, but the schema preserves two different relationships:

• Programme enrolment records what the student is officially studying and its academic status.
• Cohort membership records the intake batch to which that programme enrolment belongs.

This keeps the programme history stable if the learner later transfers, pauses, repeats with another batch, is readmitted, or enrols in another programme.

Before you start

• Admissions must contain an approved and joined admission case.
• No cancellation, resignation, or upgrade may be pending.
• The admission cycle programme must reference an available planned cohort.
• The cohort must have a pinned institute programme and published curriculum version.
• The cohort must have a pinned Student Number policy from Setup.
• The user must have the Student Section Officer or another authorised student-enrolment role.

Actors and access

Access source	Access in this epic
Institute member with Student Section Officer role	Processes ready handoffs and completes ordinary enrolment
Institute member with Student Records Officer role	Maintains permitted student and identifier information
Institute member with Academic Registrar role	Reviews conflicts, controlled corrections, and programme-level exceptions
Institute member with University Registration Officer role	Prepares and tracks university registration
Institute Admin	Views institute-level enrolment summaries; detailed student fields require the relevant functional access
Tenant Admin	Views tenant and institute summaries; does not automatically receive sensitive student data
Student	Views their own published student and enrolment information and raises corrections
Auditor role	Reads handoff, identity-match, identifier, correction, and enrolment history within scope

Screen structure and data captured

The workspace contains Enrolment Queue, Identity Match, Enrolment Review, Student Record, University Registration, Exceptions and Reconciliation, and History.

Screen 1: Enrolment Queue

The queue shows joined candidates whose handoff is:

• Ready;
• In Progress;
• Blocked by Identity Review;
• Failed and Retryable;
• Completed;
• Cancelled before completion.

Each row shows candidate name and identifier, institute, admission cycle, programme, cohort, joining date, handoff state, current blocker, and responsible officer.

The queue is restricted to the user’s institute and assigned work. It does not repeat document-verification or admission-decision controls.

Screen 2: Identity Match

The system searches existing people and students using supported identity information.

Field	Source	Meaning and validation
Candidate identity	Admissions	Name, date of birth, gender and approved identifiers from the admission case
Contact information	Admissions/candidate	Mobile, email and address available for permitted matching
Existing person candidates	System	Possible matches with the reasons and confidence indicators shown separately
Match decision	Officer	Confirm existing person, create new person, or send for review
Decision reason/evidence	Officer	Required for uncertain matches and rejected suggested matches

MedCES may suggest a match but never merges uncertain people automatically.

Screen 3: Enrolment Review

The screen shows the records that will be created before the officer completes enrolment.

Information	Entry type	Meaning and validation
Institute	Inherited	From the approved admission and cohort; read-only
Institute programme	Inherited	From the admission cycle programme; read-only
Planned cohort	Inherited	Cohort selected by the admission cycle programme; read-only
Curriculum version	Inherited	Pinned curriculum version from the cohort; read-only
Admission case	Inherited	Source case and joining evidence; read-only
Enrolment start date	Suggested/confirmed	Normally the confirmed joining or approved institutional start date
Student-number policy	Inherited	Policy version pinned to the cohort; read-only
Student number	Generated/manual	Generated at completion or entered under a Controlled Manual Entry policy
University	Inherited/selected	Applicable active university relationship
Review confirmation	Officer	Confirms the displayed target records, not a new programme or cohort choice

Screen 4: Student Record

The student page brings together identity, institute student status, programme enrolments, cohort memberships, identifiers, university registrations, and record history.

Fields are grouped by owner:

• identity fields owned by the person record;
• admission facts owned by Admissions;
• institute student fields owned by Student and Cohort Management;
• university identifiers owned by the external university and recorded by MedCES;
• academic progress owned by the relevant academic module.

The source owner is shown beside controlled fields so users do not correct information in the wrong module.

Screen 5: University Registration

Field	Required	Meaning and validation
University relationship	Yes	Active affiliating or registering university for the institute programme
Registration session	Yes	Session to which the submission belongs
Submission date/reference	Conditional	Required after submission
Submission package version	Yes after preparation	Exact data and document version sent
University status	Yes	Not Prepared, Prepared, Submitted, Accepted, Returned, Rejected, or Withdrawn
University registration number	Conditional	Recorded when issued; unique under the configured university scheme
Response date and evidence	Conditional	Required for accepted, returned, rejected, or withdrawn outcomes
Return/rejection reason	Conditional	Required when correction or escalation is needed

University registration may remain pending after institutional enrolment unless policy explicitly blocks academic activation.

Screen 6: Exceptions and Reconciliation

The screen shows:

• possible duplicate people or students;
• duplicate admission handoffs;
• invalid cohort, programme, curriculum, or policy links;
• student-number allocation failures;
• incomplete record creation;
• joined candidates without programme enrolment;
• programme enrolments without cohort membership;
• university submissions requiring correction.

Each exception shows the source record, failed rule, completed steps, safe next action, owner, and history.

Screen 7: History

History shows handoff receipt, readiness checks, identity decisions, student creation/linkage, programme enrolment, cohort membership, number allocation, university submission, correction, failure, retry, and controlled amendment. It is read-only.

Use case 1: View the enrolment handoff queue

As a Student Section Officer or Academic Registrar
I want to see joined candidates awaiting enrolment
So that every completed admission is handed into the student record once.

Acceptance criteria

• Only approved and joined candidates enter the Ready queue.
• Queue state, current blocker, assigned owner, and last attempt are visible.
• Users see only institutes and work queues within their scope.
• Completed handoffs remain searchable but cannot be processed again as new work.
• Candidate details follow Admissions field restrictions.

Use case 2: Confirm handoff readiness

As a Student Section Officer
I want to confirm the handoff is still valid
So that a cancelled, upgraded, or incomplete admission does not create an active student enrolment.

Acceptance criteria

• Approval, joining, cutoff, movement, resignation, cancellation, and prior-handoff state are rechecked at submission time.
• Programme, cohort, curriculum version, and student-number policy are validated together.
• The system identifies an existing programme enrolment created from the same admission case.
• A failed check names the owning module and record.
• The officer cannot override an Admissions decision from this workspace.

Use case 3: Match the candidate to an existing person

As a Student Section Officer
I want to decide whether the candidate already has a person record
So that MedCES does not create duplicate identities.

Acceptance criteria

• Matching uses supported identifiers and demographic attributes without exposing unrelated records.
• Each suggested match shows the fields that agree and conflict.
• A clear unique match can be confirmed by an authorised officer.
• An uncertain match is sent to review and blocks enrolment completion.
• Rejecting a strong suggestion requires a reason.
• No person records are merged automatically.

Negative cases and alternate flows

• No match: Create a new person from the approved admission identity.
• Several possible matches: Keep the handoff blocked until reviewed.
• Identity conflict: Return the relevant correction to its owning source before enrolment.

Use case 4: Create or link the institute student record

As a Student Section Officer
I want to create or link the person’s institute student record
So that all programme enrolments belong to one recognised student.

Acceptance criteria

• A new profile references the resolved person, institute, and source admission case.
• An existing compatible student profile is reused.
• A duplicate active student profile for the same person and institute is blocked.
• Student status starts from an approved system state.
• Creation or linkage is recorded with its source and actor.

Use case 5: Complete student enrolment

As a Student Section Officer
I want to complete one enrolment action
So that the student receives the correct programme enrolment, cohort membership, and student number without repeated selections.

Acceptance criteria

• Institute programme, cohort, curriculum version, and policy version are inherited and read-only.
• One programme-enrolment record is created from the approved admission case.
• One active cohort-membership record is created beneath that enrolment.
• Automatic mode allocates the student number using the cohort’s pinned policy version.
• Controlled Manual Entry validates the entered value, source, reason, pattern, and uniqueness.
• All records either complete together or remain in a safe retryable state with completed steps recorded.
• Repeating the same handoff returns the existing student, enrolment, membership, and number.
• The cohort dashboard and reconciliation counts are refreshed.

Negative cases and alternate flows

• Student-number collision: Do not issue the duplicate; keep the handoff retryable and alert the policy owner.
• Policy unavailable: Block completion and link to the pinned cohort policy.
• Cohort mismatch: Do not allow the officer to choose a different cohort; return the problem to its owning setup or admission record.
• Concurrent retry: Only one request succeeds; all others receive the completed result.

Use case 6: Record university registration

As a University Registration Officer
I want to prepare and track the student’s university registration
So that the institution can prove submission and resolve returned records.

Acceptance criteria

• The submission is prepared from approved admission, person, student, programme, and cohort data.
• The exact package version and submission reference are retained.
• Accepted registration records the university-issued number and evidence.
• Returned or rejected submissions record reason, correction owner, and deadline.
• Resubmission creates history rather than overwriting the earlier response.
• University registration does not replace the institute student number.

Use case 7: Resolve a failed or blocked handoff

As a Student Section Officer or Academic Registrar
I want to resolve the exact handoff failure
So that safe work is not repeated and incomplete records do not remain hidden.

Acceptance criteria

• The exception shows every completed and incomplete step.
• The user is directed to the owning module for source corrections.
• A retry reuses the same idempotency key and existing records.
• A blocked identity match cannot be bypassed without the required decision.
• Technical support cannot make admission or identity decisions.
• Resolution and retry outcomes are audited.

Use case 8: View the student and programme-enrolment record

As an authorised student-record, academic, or administrative user
I want to view the student’s current institutional record
So that I can understand their programme and cohort position from authoritative information.

Acceptance criteria

• The page shows student identity, institute number, admission source, programme enrolment, curriculum, cohort membership, university registration, and current status.
• Each controlled field identifies its owning module.
• Scope and field sensitivity restrict the information shown.
• Department and faculty users see only students connected to permitted academic work.
• The page links to source workspaces only where the viewer has access.

Use case 9: Correct permitted student information

As a Student Records Officer or Academic Registrar
I want to correct an authorised field with evidence
So that the record becomes accurate without silently changing admission or academic history.

Acceptance criteria

• The field’s source owner determines the correction route.
• Contact information follows the configured direct-update or approval policy.
• Legal identity changes require supporting evidence and governed review.
• Admission category, allotment, and joining facts are corrected in Admissions.
• Programme, curriculum, or cohort movement cannot be performed as a simple profile edit.
• Earlier values, reason, evidence, actor, and approval remain visible.

Use case 10: Student reviews their record

As a Student
I want to view my own student and enrolment information
So that I can identify incorrect information early.

Acceptance criteria

• The student sees their own institute number, programme, curriculum version, cohort, enrolment status, and university-registration status.
• Sensitive internal notes and other students are not visible.
• The student can raise a correction request with evidence.
• The student cannot directly rewrite official fields or approve the request.
• Request owner and status are visible.

Use case 11: Reconcile admission and enrolment counts

As a Student Section Officer, Academic Registrar, or Auditor
I want to compare joined candidates with completed student enrolments
So that every missing or duplicate handoff is identified.

Acceptance criteria

• The view compares joined candidates, student profiles, programme enrolments, cohort memberships, issued student numbers, and university submissions.
• Differences link to the specific handoff or record.
• Counts state their source and calculation time.
• Users cannot fix a difference by overwriting a total.
• Reconciliation respects institute scope and sensitive-field access.

Use case 12: View enrolment history

As a Student Records Officer, Academic Registrar, or Auditor
I want to review the complete enrolment history
So that identity, identifier, membership, and registration decisions can be explained.

Acceptance criteria

• History includes handoff readiness, identity match, student creation/linkage, enrolment, cohort membership, number allocation, university registration, corrections, failures, and retries.
• Every event includes actor, role grant, scope, time, reason, source, and earlier/new value where applicable.
• History is read-only.
• Export follows the viewer’s current access and field restrictions.

Business rules

• Admission approval and joining are both required before ordinary student enrolment.
• One user action creates the programme enrolment, cohort membership, and student number.
• Programme, cohort, curriculum, and identifier policy are inherited during ordinary handoff and cannot be reselected.
• A programme enrolment and cohort membership are separate records even though they are created together.
• One admission case cannot create two active programme enrolments.
• One programme enrolment cannot have duplicate active membership in the same cohort.
• Every student number follows the policy version pinned to the cohort.
• Issued student numbers are never recycled.
• University registration number and institute student number are different identifiers.
• Identity, admission, student, university, and academic fields are corrected through their owning records.
• Failed work remains safe to retry and never hides partial outcomes.

Technical design

How the records relate

admission.admission_case
└── admission.enrolment_handoff
    └── people.person
        └── student.student_profile
            └── student.programme_enrolment
                ├── student.cohort_membership -> student.cohort
                ├── student.student_identifier
                └── student.university_registration

Conceptual schema

Record	Important fields
admission.enrolment_handoff	admission case, target cohort, handoff key, state, current step, error, last attempt
people.person_match_review	candidate person, possible person, compared fields, decision, evidence, reviewer
student.student_profile	person, institute, source admission case, student status, validity
student.programme_enrolment	student, institute programme, curriculum version, admission case, start date, status
student.cohort_membership	programme enrolment, cohort, membership type, start/end dates, status
student.student_identifier	student, programme enrolment, type, value, issuer, policy version, source, status, issued at
student.cohort_identifier_policy	cohort, identifier type, pinned policy version, resolution reason, pinned at
student.university_registration	programme enrolment, university relationship, session, submission version/reference, state, university number, evidence
student.student_correction_request	student, field/source record, requested value, evidence, owner, state, decision
student.enrolment_state_event	enrolment, earlier/new state, actor, role grant, reason, source, timestamp

Process-layer responsibilities

The process layer must:

• recheck approval, joining, movement, cancellation, and existing handoff state;
• match identities without leaking unrelated person or student data;
• prevent automatic uncertain merges;
• validate cohort, programme, curriculum, and policy version together;
• create or reuse the student, programme enrolment, membership, and identifier exactly once;
• allocate automatic numbers atomically or validate controlled manual numbers;
• preserve completed steps and safely retry a partial failure;
• direct corrections to the record that owns the field;
• calculate reconciliation from authoritative source records;
• apply organisational scope, functional role, assignment, record-state, and field-level access;
• audit every material identity, enrolment, identifier, registration, and correction action.

Success outcome

Every approved and joined candidate becomes one correctly identified student with one programme enrolment, one cohort membership, one traceable institute student number, and a complete handoff history.