Department Units and Clinical Teams

Epic summary

The Department Units and Clinical Teams workspace defines the clinical or teaching units that operate within an institute department.

The normal structure is:

Institute
└── Department of General Medicine
    ├── Medicine Unit 1
    ├── Medicine Unit 2
    └── Medicine Unit 3

A unit is optional. It is created only where the department genuinely works through named units or another recognised subdivision. A department such as General Medicine may use inpatient clinical units, while a diagnostic or pre-clinical department may use laboratory sections, diagnostic services, or no subdivision at all.

The unit becomes an organisational scope beneath its department. This lets MedCES answer questions such as:

which units can deliver a clinical posting;
which faculty and residents are attached to each unit for a given period;
which wards, beds, outpatient areas, or other clinical locations a unit may use;
how many learners and concurrent groups the unit can support; and
whether an assigned supervisor is valid for the scheduled posting.

The unit is not a ward, a room, a person, or a clinical posting. Those are connected records with their own dates and responsibilities.

Before you start

The institute and department must already exist in the Organisation Hierarchy. Clinical sites and locations should exist before they are allocated to a unit. Verified faculty and resident records are needed only when named people are assigned.

Actors and access

Access source	Access in this epic
Institute member with Academic Registrar role	Creates draft units and coordinates structural approval
Institute member with Organisation Approver role	Approves units and major changes according to institute policy
Department Admin, normally with HOD appointment	Maintains units within the department and confirms teaching capacity
Unit Admin, normally with Unit Head appointment	Reviews the unit profile, team, locations, and scheduling capacity
Institute member with Faculty Records role	Confirms that faculty and resident assignments agree with source appointments
Institute member with Clinical Posting Coordinator role	Uses published units when preparing delivery and schedules
Institute member with Facilities Officer role	Confirms ward, bed, room, and other location allocations
Auditor role	Views the unit structure, assignments, approvals, and history without editing

What the user does

The workspace contains six screens:

Department Unit List
Unit Profile
Clinical Locations and Capacity
Clinical Team Assignments
Teaching Availability
Review and History

Screen 1: Department Unit List

The user selects a department and sees its current, future, and historical units.

Field or filter	What it shows
Institute and department	The organisational owner of the units
Unit name and code	The institute’s recognised unit identity
Unit type	Inpatient clinical unit, diagnostic section, laboratory section, clinical service, field-practice unit, or another approved type
Primary site	The normal institute clinical site, where applicable
Unit head	Current effective-dated unit-head assignment
Status	Draft, Under Review, Published, Suspended, or Archived
Effective period	When the unit exists in the hierarchy
Readiness	Whether required people, locations, and capacity information are complete

Departments that do not use units remain valid. MedCES must never require artificial Unit 1 records merely to complete setup.

Screen 2: Unit Profile

Field	Required	What the user defines
Parent department	Yes	Active department in the same institute
Unit name	Yes	Real name used by the institute, such as Medicine Unit 1
Unit code	Yes	Code unique within the parent department
Unit type	Yes	Controlled type appropriate to the department’s work
Primary clinical site	Conditional	Normal institute site at which the unit operates
Service description	Yes	Plain description of the clinical and teaching work performed
Effective dates	Yes	Period for which the unit is active
Status	Yes	Draft, Under Review, Published, Suspended, or Archived
Source/approval	Yes for publication	Institute order, approved structure, or another supporting record

The system derives the unit’s LTREE path from its stable ID. Renaming the unit does not change its identity.

Screen 3: Clinical Locations and Capacity

A unit may work in several locations, and one location may be used by several units at different times. The user therefore allocates locations instead of placing wards beneath units in the organisation tree.

Field	Required	What the user defines
Unit	Yes	Published or draft department unit
Site	Yes	Institute clinical site at which the location exists
Ward, OPD, procedure area, lab, or other location	Yes	Record from the separate facility tree
Allocation type	Yes	Primary, shared, sessional, on-call, or another controlled arrangement
Bed count	Conditional	Beds available to the unit during the allocation period
Service days/times	No	When the unit normally uses the location
Effective dates	Yes	Validity of the allocation
Confirmation	Yes	Department and facilities confirmation state

Bed numbers and staffing patterns are stored as effective-dated facts or rule evaluations. They are not permanently hard-coded into the unit type because requirements differ by speciality and can change over time.

Screen 4: Clinical Team Assignments

The unit has a team, but people do not become child nodes in the hierarchy.

Field	Required	What the user defines
Person	Yes	Verified faculty, resident, or other eligible clinical teacher
Assignment role	Yes	Unit Head, faculty member, Senior Resident, Junior Resident, posting supervisor, or another supported role
Primary/additional assignment	Yes	Whether this is the person’s normal unit or an additional assignment
Effective dates	Yes	Assignment or rotation period
Source appointment/rotation	Conditional	HR appointment, resident rotation, or approved order supporting the assignment
Teaching eligibility	System evaluated	Whether the person may supervise, assess, or sign off the selected activity
Approval state	Yes	Draft, Confirmed, Approved, Ended, or Cancelled

Unit Head, Head of Department, postgraduate guide, posting supervisor, and system permission are separate responsibilities. One person may hold several of them, but MedCES records each relationship independently.

Screen 5: Teaching Availability

This screen records the unit’s ordinary planning limits. It does not create a timetable.

Field	Required	What the user defines
Supported posting/activity types	Yes for teaching use	Ward, OPD, emergency, procedure, bedside teaching, laboratory, community, or another supported type
Maximum concurrent learners	Yes for teaching use	Safe planning capacity for the stated activity
Maximum concurrent groups	Conditional	Number of learner groups the unit can support at once
Learner-to-supervisor ratio	Conditional	Planning limit where required
Ordinary availability	No	Days and time windows Academic Planning and Delivery may prefer
Required location/capability	Conditional	Location or capability that must be available with the unit
Required supervisor role	Conditional	Eligible role that must be present
Effective dates	Yes	Period for which the capacity information applies

Curriculum Delivery Setup later decides that a particular curriculum posting may use the unit. Academic Planning and Delivery then chooses the actual dates, learner group, location, and named supervisor.

Screen 6: Review and History

Before publication, MedCES shows:

missing parent, type, dates, or approval evidence;
overlapping unit codes within the department;
a Unit Head whose institute or department appointment is not valid;
location allocations outside the site’s or unit’s active dates;
teaching capacity without an eligible supervisor role;
future schedules and assignments affected by a proposed change.

The history view shows the unit structure and its team, location, and capacity records as of a selected date.

Worked example: General Medicine units

The institute creates three units beneath the Department of General Medicine. Medicine Unit 2 is configured as follows:

Parent department: Department of General Medicine
Unit type: Inpatient clinical unit
Primary site: Institute Teaching Hospital
Locations: Medicine Ward B and General Medicine OPD
Bed allocation: 20 beds, effective 1 July 2026
Unit Head: Professor B, effective 1 July 2026
Team: 1 Associate Professor, 2 Assistant Professors,
      1 Senior Resident, and rotating Junior Residents
Teaching capacity: 10 MBBS learners per posting group
Supported activities: Ward posting, bedside teaching, and OPD posting

Curriculum Delivery Setup can now approve Medicine Unit 2 as a delivery option for the applicable General Medicine posting. Academic Planning and Delivery may create a posting block only when the unit, selected location, and eligible supervisor are all valid for the block dates.

Use case 1: Create a department unit

As a Department Admin with HOD appointment
I want to create a real clinical unit beneath my department
So that its people, locations, capacity, and teaching work can be managed separately.

Acceptance criteria

The parent is an active department in the same institute.
Unit code, name, type, effective dates, service description, and source are recorded.
The unit receives a system-generated LTREE path beneath the department.
A department may operate without units.
Publication follows the institute’s configured approval process.

Use case 2: Assign faculty and residents to a unit

As a Department Admin with HOD appointment
I want to record who works in each unit and for what period
So that Academic Planning and Delivery and supervision checks use the correct team.

Acceptance criteria

Every named person has a valid institute placement or approved external relationship.
The person’s department association covers the assignment period where required.
The role and effective dates are explicit.
Resident rotations can end without removing their historical unit membership.
Assigning a person to a unit does not grant system access.

Use case 3: Allocate clinical locations and beds

As an institute member with Facilities Officer role
I want to confirm which locations and beds a unit may use
So that capacity and scheduling checks reflect the institute’s real arrangements.

Acceptance criteria

The site and location exist in the facility tree.
Allocation type, capacity where applicable, dates, and confirmations are recorded.
Shared and sessional allocations are supported.
One ward is not forced to belong permanently to one unit.
Conflicting allocations are shown before approval.

Use case 4: Make a unit available for clinical postings

As an institute member with Clinical Posting Coordinator role
I want to record the activities and learner capacity supported by a unit
So that curriculum delivery and Academic Planning and Delivery can select only feasible options.

Acceptance criteria

Supported activities, capacity, validity, and any supervisor or location requirements are explicit.
Capacity is checked against the effective team and location allocations.
Publishing availability does not create a schedule.
The curriculum-to-unit mapping is completed in Curriculum Delivery Setup.
The actual block, learner group, location, and named supervisor are selected in Academic Planning and Delivery.

Use case 5: Change or close a unit safely

As an institute member with Academic Registrar role
I want to reorganise or close a unit from a future date
So that the current structure changes without rewriting past postings and supervision.

Acceptance criteria

The impact view lists future posting blocks, learners, supervisors, location allocations, and curriculum mappings.
A unit with affected future schedules cannot be closed until those schedules are moved or cancelled.
Historical postings continue to show the unit that delivered them.
A merger or split creates explicit successor relationships instead of silently changing historical identity.

Business rules

A department unit has one structural parent: its department.
Units are optional and their supported types depend on the department’s real operating model.
A department grant may reach its units; a unit-level grant does not reach sibling units or the whole department.
Faculty, residents, and other people are connected through effective-dated assignments, not placed beneath the unit in the LTREE.
Wards, rooms, laboratories, and beds remain in the facility model and are allocated to units through separate records.
A unit may use several locations, and a location may support several units where dates and capacity allow.
Head of Department, Unit Head, postgraduate guide, posting supervisor, and permission grant are separate relationships.
Curriculum requirements describe what learners must complete. Unit setup describes available delivery capacity. Academic Planning and Delivery creates the actual posting block.
Published historical units and assignments are never physically deleted while referenced.
A unit at an affiliated external hospital is recorded under that learning site and linked to the institute; it is not inserted into the institute’s LTREE as if the institute owned it.

Technical design

How the records relate

org department entity
  -> org department-unit entity
       -> academic.faculty_unit_association
       -> facility.unit_location_allocation
       -> academic.unit_teaching_capacity

academic.clinical_posting_requirement
  -> academic.delivery_unit_eligibility
       -> org department-unit entity
  -> planning.clinical_posting_block
       -> unit + location + learner group + named supervisor

Conceptual schema

Record	Important fields
`org.entity`	stable unit identity, tenant, `DEPARTMENT_UNIT` type, code, current version, status
`org.entity_version`	unit identity, parent department, LTREE path, name, validity, source, approval
`org.department_unit_profile`	entity ID, unit type, primary site, service description, source, approval
`academic.faculty_unit_association`	unit, person/placement, association role, primary flag, source, validity, approval state
`facility.unit_location_allocation`	unit, site, location, allocation type, bed count, service pattern, validity, confirmation
`academic.unit_teaching_capacity`	unit, activity type, learner/group capacity, supervisor ratio/role, required capability, availability, validity
`academic.delivery_unit_eligibility`	posting delivery mapping, department unit or external-site unit, allowed/primary status, validity, confirmation
`org.unit_successor_relationship`	old unit, successor unit, split/merge/replace type, effective date, reason

Process-layer responsibilities

The process layer:

validates that a unit belongs beneath an active department in the same institute;
maintains the unit’s effective-dated hierarchy path;
checks people against institute placement, department association, role eligibility, and assignment dates;
checks unit/location/site dates and detects capacity conflicts;
gives Curriculum Delivery Setup a list of valid units for a posting requirement;
gives Academic Planning and Delivery effective-dated unit, location, capacity, and eligible-supervisor options;
prevents future posting blocks from using a closed or unavailable unit; and
preserves the unit and team recorded on completed schedules and learner evidence.

It does not:

treat a national staffing pattern or bed number as permanently true for every speciality;
place wards or people in the organisation LTREE;
decide which curriculum requires a posting;
create learner groups, posting blocks, attendance, or competency evidence; or
grant access merely because a person is assigned to the unit.

Success outcome

MedCES represents the institute’s real department units without inventing them where they do not exist, and Academic Planning and Delivery can select a valid unit, location, team, and capacity for every clinical posting block.