SUMMARY

1. Capacity Domains & Functional Areas: Where workload is generated
2. Workload Objects: What workload is generated
3. Conversion Archetypes: How workload is converted into capacity
4. Classification Logic and Subgroups: How activity is partitioned and routed
5. Assumptions: Parameters used to derive workload and capacity

Conventions¶

1. Capacity Domains & Functional Areas¶

A capacity domain is a real-world resource type that consumes workload and produces capacity e.g. A&E bays, Critical care beds, Maternity birth rooms, SDEC spaces etc. It's an operational concept.

A functional area is the modelling construct used to represent a capacity domain within the framework. It combines capacity domain + activity definition + workload derivation + capacity conversion method + assumptions. It's a modelling concept. e.g. BAYS_AE, BEDS_CRITICAL_CARE, ROOMS_MATERNITY_BIRTH, SPACES_SDEC.

A functional area is the framework's modelling representation of a capacity domain, defining how activity is classified, transformed into workload and converted into capacity requirements.

Functional area subgroups¶

Functional areas are defined by distinct capacity domains. Activity cohorts that consume the same underlying capacity resource are represented as subgroups within a functional area. Separate functional areas are created only where activity consumes a materially different capacity resource.

• Does activity belong to a different cohort/pathway, requiring different assumptions?
• If YES, requires a new subgroup
• Does activity consume a different capacity resource?
• If YES, requires a new functional area

Naming convention¶

Functional area identifiers follow the pattern: <CAPACITY_TYPE>_<CAPACITY_DOMAIN>.

2. Workload Objects¶

Purpose¶

Workload objects are standardised representations of resource consumption generated by activity. They provide a common interface between workload derivation and capacity conversion, allowing different functional areas to be modelled using consistent workload measures and reusable conversion archetypes.

Workload objects are resource-specific. The object is not defined solely by its unit e.g. 'assessment bed days' are different from 'ward bed days'. Both are measured in bed days but they represent different workload objects. Objects are defined by resource meaning + measurement unit.

Workload object types¶

Workload objects may be directly observed, derived or residual.

1. Directly observed or estimated from activity (activity x workload assumptions). Examples: occupancy hours, procedure hours, appointment hours, treatment sessions, overnight bed days
2. Derived created by partitioning, allocating or transforming another workload object. Examples: critical care bed days, assessment bed days, birth room bed days
3. Residual derived workload objects representing the workload remaining after allocations to specialist operational domains have been deducted

Example:

Canonical workload families¶

1. Bed-day workload objects e.g. * bed days
2. Time-based workload objects e.g. occupancy hours, procedure hours, treatment hours, appointment hours
3. Throughput workload objects e.g. treatment sessions

Relationship to conversion archetypes¶

Workload objects are archetype inputs. They are the standardised interface between workload derivation and capacity conversion.

Workload objects should be defined using the smallest set of standardised workload families necessary to support capacity conversion.

Each conversion archetype defines the workload object(s) it can consume.

Naming Convention¶

Workload object names should describe both the operational meaning and measurement unit.

Workload objects follow the pattern: <WORKLOAD_CONCEPT>_<UNIT> e.g. occupancy hours, ward bed days

The prefix describes the operational workload concept. The suffix tells you the measurement unit.

3. Conversion Archetypes¶

Purpose¶

Conversion archetypes are reusable workload-to-capacity conversion methods. They define how standardised workload objects are converted into capacity requirements under a given set of operational constraints. Archetypes promote consistency across functional areas by providing common conversion approaches for similar capacity domains. Rather than each functional area defining its own capacity conversion method, functional areas reuse an existing archetype wherever possible.

Conversion archetypes form the interface between workload objects and capacity outputs.

New archetypes should only be introduced where an existing archetype cannot adequately represent the operational mechanism constraining capacity. New functional areas should preferentially reuse existing archetypes. Creation of new archetypes should be considered exceptional and require justification.

Archetype families¶

Conversion archetypes are grouped into families based on the operational mechanism constraining capacity.

Archetype responsibilities¶

Each archetype defines:

1. Workload object(s) consumed The workload object family accepted as input to the archetype.
2. Operational constraint The operational mechanism limiting capacity (e.g. occupancy, utilisation, throughput).
3. Denominator structure The generic workload-to-capacity conversion formula.
4. Operational assumptions required The operational parameters required to calculate capacity (e.g. occupancy, utilisation, annual operational hours).
5. Capacity output type The type of capacity produced (e.g. beds, bays, rooms, theatres, spaces).

Functional area relationship¶

Each functional area maps to a single conversion archetype. Many functional areas may reuse the same archetype where they share a common operational constraint and workload-to-capacity conversion method.

Examples:

Relationship to workload objects¶

Conversion archetypes consume workload objects and convert them into capacity outputs. Each archetype defines the workload object family it can consume.

Workload objects should be defined using the smallest set of standardised workload families necessary to support archetype reuse.

Naming convention¶

Conversion archetypes follow the pattern: FRM_<ARCHETYPE> e.g. FRM_FLOW_SPACE, FRM_RECOVERY_OCCUPANCY, FRM_TIME_UTIL

The prefix denotes a reusable framework conversion archetype. The suffix describes the generic workload-to-capacity conversion method represented by the archetype.

4. Classification Logic and Subgroups¶

Purpose¶

Classifications are reusable activity-routing rules used to identify cohorts, pathways and operational domains within source activity data. They provide a common vocabulary for functional area specifications and prevent activity-selection logic from being repeatedly defined across the framework.

Classification design principles¶

• Classifications should be reusable across functional areas wherever possible
• New classifications should only be created where an existing classification cannot adequately represent the activity cohort
• Differences in assumptions or workload derivation do not by themselves require new classifications

Classification vs subgroup¶

A classification e.g. CLASS_ELECTIVE, CLASS_RENAL, CLASS_ZERO_DAY is a reusable activity-selection rule.

A subgroup e.g. 'adult elective medical', 'adult elective surgical', 'renal regular day/night' is a modelling construct that exists because:

• assumptions differ
• workload derivation differs
• capacity outputs differ
• or CTM traceability differs

Classification composition¶

Subgroups are typically defined through the composition of multiple classifications.

Example: CLASS_DAYCASE + CLASS_AGE_ADULT + CLASS_SURGICAL combine to define the subgroup 'adult surgical daycase'.

Classification types¶

Classification types are descriptive metadata used to aid interpretation and organisation of the classification register. They are not referenced by model logic and may be added, removed or refined without affecting framework behaviour. The framework also distinguishes between classification definitions and their implementation. Some classifications may be implemented using separately maintained lookup tables where this improves maintainability or reuse.

Relationship to functional areas¶

Classifications identify activity eligible for inclusion within a functional area. Functional areas may reference a single classification or multiple classifications; and the same classification may be reused across multiple functional areas. For example: CLASS_AGE_ADULT is reused across multiple functional areas.

Relationship to CTM¶

CTM rows reference classifications rather than embedding filtering logic. This ensures activity-selection rules are defined once and reused consistently across functional areas.

Naming convention¶

Classification rules follow the pattern: CLASS_<CONCEPT>.

Examples:

• CLASS_ELECTIVE
• CLASS_RENAL
• CLASS_AGE_ADULT
• CLASS_ZERO_LOS
• CLASS_SURGICAL

5. Assumptions¶

Purpose¶

Assumptions are governed numerical parameters used to support workload derivation and capacity conversion. They represent quantities that are not derived directly from source activity data or that are intentionally standardised across the framework. Assumptions are maintained separately from functional area specifications to promote consistency, transparency and ease of maintenance.

Assumptions describe expected operational behaviour for modelling purposes. They do not represent performance targets, service standards or policy commitments.

Assumption design principles¶

• Assumptions should be reusable wherever possible
• Assumptions should be maintained independently of model logic
• New assumptions should only be created where an existing assumption cannot adequately represent the required parameter
• Assumptions should be assigned stable identifiers to support traceability and implementation
• Changes to assumption values should not require changes to functional area specifications, workload derivations or conversion archetypes

Assumption categories¶

The framework distinguishes between two broad categories of assumptions.

1.Workload assumptions¶

Workload assumptions describe how activity consumes resources, and are used to convert activity into workload objects.

Examples: LOS, procedure time, consultation time, treatment duration, DNA rate, DNA time

2. Operational assumptions¶

Operational assumptions describe how resources are operated, and are used to convert workload objects into capacity outputs.

Examples: occupancy, utilisation, annual operational hours, annual operational days, sessions per day

Assumption scope¶

Assumptions may apply at the level of functional area or subgroup.

Examples:

• DAYCASE_RECOVERY_OCC is scoped to the functional area BEDS_DAYCASE_RECOVERY
• AE_ADULT_MINOR_LOS is scoped to the subgroup 'adult minor' in the functional area BAYS_AE

Relationship to functional areas¶

Functional areas reference assumptions but do not define them.

Functional area specifications identify:

• which assumptions are required
• where assumptions are applied
• and how they influence workload derivation or capacity conversion

Assumption values are maintained separately within the assumptions register.

Relationship to CTM¶

CTM rows reference assumption identifiers rather than embedding assumption values. This ensures calculation logic remains stable when assumptions are updated.

Naming Convention¶

Assumption identifiers should describe the most specific modelling scope to which the assumption applies, followed by the parameter being represented.

The pattern is: <SCOPE>_<PARAMETER>

Where: <SCOPE> = functional area or subgroup

Examples:

• DAYCASE_RECOVERY_OCC is scoped to the functional area BEDS_DAYCASE_RECOVERY
• AE_ADULT_MINOR_LOS is scoped to the subgroup 'adult minor' in the functional area BAYS_AE