Setup Readiness
Epic summary
The Setup Readiness workspace is the control centre for institutional setup. It does not show one misleading overall percentage. It explains which operational capabilities are ready, which are blocked, and what an authorised user must complete next.
A new institute can become institution-ready before it becomes admissions-ready or academic-delivery-ready. Readiness is therefore evaluated by capability and organisational scope.
Before you start
Readiness can be opened at any time, but its result improves as the institute completes Setup. MedCES checks the published setup for the selected institute or programme. It also checks whether required functional roles and standing academic assignments have been assigned.
Readiness never repairs or approves another epic’s data. It links the user to the owning workspace.
Actors and access
| Access source | Access in this epic |
|---|---|
| Tenant Admin or Governance Registrar role | Views readiness across authorised institutes |
| Institute member with Setup Approver role | Reviews and acknowledges institute-level readiness and risk |
| Institute member with Academic Registrar role | Coordinates remediation and opens the relevant Setup record |
| Department Admin | Views blockers assigned to their department |
| Institute member with Identifier Policy Manager role | Resolves student-number policy and sequence blockers |
| Auditor role | Views current and historical readiness evidence |
Screen structure and data captured
The workspace contains Scope Selector, Readiness Summary, Capability Details, Assigned Actions, and History.
| Field or indicator | Meaning |
|---|---|
| Scope | Tenant, governing organisation, institute, or institute programme being assessed |
| Capability | Institution Setup, Student and Cohort Management, Admissions, Academic Planning and Delivery, Attendance, Competency and Logbook, Regulatory Reporting, or another registered capability |
| Readiness state | Not Started, In Progress, Ready, At Risk, or Blocked |
| Blocking check | A failed hard prerequisite with the owning epic and affected record |
| Warning | A non-blocking issue, such as a relationship expiring soon |
| Effective date | Date for which readiness is being evaluated |
| Source versions | Published setup versions used by the evaluation |
| Responsible office | Entity or capability expected to resolve the item |
| Last evaluated | System time and evaluation correlation identifier |
Use case 1: Review institute readiness
As an institute member with the required Setup Approver role
I want to see whether my institute is ready for each MedCES capability
So that operations begin only with complete and approved foundations.
Acceptance criteria
- The system evaluates each capability independently for the selected effective date.
- Every failed check names the missing, expired, conflicting, or unpublished record.
- The result identifies whether the blocker is at platform, tenant, institute, programme, department, or unit scope.
- The user can open the owning record when they have view access.
- A Ready state displays the exact setup versions that produced it.
Negative cases and alternate flows
- No institute configured: Show Institution Setup as the first blocker.
- Insufficient access: Show that a required record exists without exposing restricted values.
- Evaluation unavailable: Display the last successful result as stale; never present it as current.
Use case 2: Resolve an assigned blocker
As an institute member with Academic Registrar role
I want to work through blockers in setup order
So that I do not configure downstream records against incomplete foundations.
Acceptance criteria
- Blockers are ordered by the step that must be completed first and by seriousness.
- The assigned office, responsible capability, due date, and remediation link are shown.
- Completing a draft does not clear the blocker until the required version is published.
- Publication triggers recalculation without a manual “mark complete” action.
- The history preserves when the blocker appeared and when it was resolved.
Use case 3: Compare readiness across institutes
As a tenant member with Governance Registrar role
I want to compare readiness across authorised institutes
So that shared risks and delayed institutes can be addressed before operations begin.
Acceptance criteria
- The view includes only institutes inside the user’s descendant scope.
- A summary can be filtered by capability, state, programme, due date, and responsible office.
- Aggregation never hides the institute-specific cause.
- Export contains evaluation time and source version identifiers.
Business rules
- Users cannot manually set a readiness state.
- An approved, time-limited exception can change a check outcome only when the check explicitly permits exceptions.
- A warning becomes a blocker automatically when an expiring record becomes required for continued operation.
- A hierarchy or ownership change triggers reevaluation for all descendants and dependent records.
- A clinical unit used by curriculum delivery or Academic Planning and Delivery is not ready when its parent department, team assignment, required location allocation, or teaching capacity is invalid for the applicable dates.
- A cohort is not ready for Admissions when no applicable published Student Number policy can be pinned from an institute override or tenant fallback.
Technical design
Conceptual schema
| Record | Important fields |
|---|---|
setup.readiness_capability | code, name, evaluator_key, scope_types, active |
setup.readiness_rule | capability_id, check_code, required_record_type, severity, exception_policy, evaluator_version |
setup.readiness_evaluation | scope_entity_id, capability_id, effective_on, state, evaluated_at, correlation_id |
setup.readiness_result | evaluation_id, check_code, outcome, provider_type, provider_id, provider_version, message_code |
workflow.remediation_task | result_id, responsible_entity_id, required_capability, due_at, state |
Process-layer responsibilities
- Build the applicable rule set from scope, programme shape, and requested capability.
- Check that every required published record is valid on the effective date.
- Resolve the applicable identifier policy and verify that its variables and sequence can be used for the intended cohort.
- Evaluate hard blockers and warnings using registered, versioned evaluators.
- Produce an explainable result rather than storing a manually editable summary.
- Recalculate only affected scopes when a required setup record changes.
- Preserve prior evaluations for audit and operational evidence.
Success outcome
The institution knows which capabilities can safely operate and receives an exact, auditable route to resolve every blocker.