WF-12 — Simulation and Learning-Resource Readiness

Be honest about the yield here, because overselling it would misdirect effort. Simulation carries no OBEF KPI of its own. Its OBEF contribution is indirect and, on any realistic estimate, modest: it raises the quality of assessments that KPI 2.1's reviewers will see, it raises the course evaluation scores that KPI 2.6 aggregates, it can qualify sessions for KPI 3.3 where health-system partners co-deliver them, and it fills a handful of facility fields in the institutional templates. The case for this workflow is educational quality first and OBEF second. That ordering is deliberate and should survive contact with a committee paper.

1. Purpose

To ensure that every simulation-based and resource-dependent learning activity at IoL runs with equipment that is serviceable and prepared, faculty who are trained to facilitate and to debrief, scenarios that are version-controlled and mapped to learning outcomes, and a record of what was delivered, by whom and for how many contact hours, so that the educational experience is reliable, the assessment built on it is defensible, and the partner contribution inside it is visible to the framework that counts it.

2. Scope

Scope statement. This process manages simulation and learning-resource readiness from the request for a simulation-based or resource-dependent session, through scenario preparation, equipment and environment readiness, faculty preparation and delivery, to debriefing quality assurance, session recording and the annual reporting of facility and operations data.

Applies to. All simulation-based teaching and assessment supporting PGDipHPE and MScHPE; teaching observation and microteaching sessions; standardised participant and simulated learner encounters; skills-based sessions using IoL or shared MBRU facilities; the learning resources those sessions depend on; and simulation sessions co-delivered with named clinical partners from health-system organisations.

Does not apply to. Clinical simulation delivered by other MBRU colleges for their own programmes, which IoL may support but does not own; the design of the assessment instrument used in a simulation-based assessment, which is WF-09; the placement itself, which is WF-13; and the appointment or development of faculty, which is WF-08. This workflow consumes WF-08's competence records and does not create them.

Applicable requirements. OBEF guide v11.5 KPI 2.6, KPI 2.1 and KPI 3.3 qualification criteria; the institutional facility and operations fields in Institute - Overview.xlsx and Institute - Operations.xlsx; CAA requirements for learning resources and facilities adequate to the programme; MBRU health, safety and infection-control policy; simulation good practice for briefing, psychological safety and debriefing; data protection where sessions are recorded.

The structural fact that shapes everything below. Simulation has no Program Code. It is a Channel C3 capability. Nothing it produces can be submitted as a programme row. It reaches the score only by improving something that is measured elsewhere, or by being an attribute of a course that is measured elsewhere. Every capture point in this workflow therefore has to stamp either a Program Code borrowed from the course it serves, or an institutional identifier, or it scores nothing at all.

3. Trigger, boundary and endpoint

4. SIPOC

5. Accountability

Process owner. IoL lead for simulation and learning resources, or the role able to commit facility capacity, approve equipment investment and require faculty preparation before delivery.

Escalation.

6. Process steps

1. Receive and accept the session request. Learning outcomes, cohort, date, assessment status, Program Code. [CAPTURE] session identity, Program Code, Course code, Course Ref Number, academic period. Serves 2.1, 2.6 and 3.3 by giving an institutional capability a programme identifier. Decision point. A session without a Program Code cannot contribute to any programme-level KPI. If the session genuinely serves both programmes, record both codes rather than choosing one.

2. Select the scenario and record its version. [CAPTURE] scenario identifier, version, date of last review, the learning outcomes it addresses. Serves 2.1, through the reliability sub-question in criterion 2, where the session is assessed. Scenario version control is the simulation analogue of the assessment item-reuse register. A scenario used unchanged across four cohorts is the same reliability and recycling problem as a reused examination item, and a scenario changed silently between cohorts makes the assessment built on it incomparable. Version, date, and reason for change, every time.

3. Confirm equipment and environment readiness. Pre-session check against a documented list: manikins and task trainers functioning, consumables present, audiovisual and debriefing capture working, room configured, safety and infection-control requirements met. [CAPTURE] readiness sign-off, checker, date and any defect. Serves 2.6 directly, since nothing degrades a learner's rating of a session faster than equipment that does not work. Exception route. A failed check stops the session or triggers a documented substitution. Running a session on equipment known to be faulty and hoping is how a simulation programme loses its credibility with clinicians who use the real thing daily.

4. Confirm faculty and debriefer competence. Check the named facilitator and debriefer against the competence record maintained by WF-08. [CAPTURE] named faculty, named debriefer. Serves 2.1 and 2.6. Debriefing is where simulation learning actually happens, and it is the part most often delivered by whoever is available. Requiring a recorded debriefing competence, and refusing to run without one, is the highest-value quality control in this workflow. It has no OBEF weight attached to it, and it is still the right rule.

5. Confirm and record the partner contribution. Where a Dubai Health entity or other health-system organisation co-delivers the session, record the named individual, their organisation, a working email and the hours they will lead. [CAPTURE] partner identity and planned hours. Serves 3.3. Decision point. For KPI 3.3, a session counts toward the delivered-in-partnership route only if the partner is named in the syllabus, the session is on the formal timetable or documented in the LMS, the sessions are linked to learning outcomes or assessment, and the partner delivers at least 20% of the course's contact hours and never fewer than 10 hours. A single guest simulation session almost never clears the 10-hour floor on its own. Record it anyway, because the threshold is tested at course level in WF-03 and several sessions may aggregate.

6. Brief learners and faculty. Outcomes, roles, ground rules, psychological safety, and how the session will be assessed if it is assessed.

7. Deliver the session. [CAPTURE] actual contact hours delivered, split between IoL faculty and partner contributors, and the number of learners present. Serves 3.3 and the Operations_Average_Class_Size and Operations_Average_Lab_Size returns. Record actual hours, never planned hours. WF-03 will test the 20% share and the 10-hour floor against this figure, and a planned figure recorded as actual is exactly the kind of claim that fails an Appendix B evidence request.

8. Debrief. Structured, by a competent debriefer, with time protected for it.

9. Capture debrief quality. Use a consistent instrument, whether an observed-debriefing rating or a structured self-and-learner review. [CAPTURE] debrief quality record. Serves 2.6 and, where the session is assessed, 2.1 criterion 4 on feedback. In a simulation-based assessment, the debrief is the feedback that KPI 2.1's fourth criterion asks about. Recording its timeliness and quality is not an extra: it is the evidence for a rubric criterion.

10. Collect learner feedback for the session. Feed it to the course evaluation run by WF-06, so it reaches Course evaluations score. [CAPTURE] per-question raw responses with issue and collection dates. Serves 2.6. Appendix B permits the Ministry to demand raw per-participant per-question course evaluation data with dates. A session-level instrument that is not retained in that form is not usable as evidence, however useful it is internally.

11. Close the session record. Scenario version, equipment sign-off, named faculty and debriefer, partner contribution, actual hours, attendance, debrief quality, feedback. One record, closed within ten working days.

12. Update facility and operations data annually. [CAPTURE] Overview_Facilities_Labs, Overview_Lab_Count, Overview_Facilities_Student Services, Overview_Activities_Center, Overview_Special_Needs_Availability in Institute - Overview.xlsx, and Operations_Average_Class_Size, Operations_Average_Lab_Size in Institute - Operations.xlsx. Serves no KPI directly; these are institutional descriptive fields that CAA and the Ministry both read, and a null in them describes an institution with no facilities.

7. OBEF data generated

Capture rule. Three things must be recorded at the time and cannot be reconstructed afterwards: the actual contact hours and their split between IoL and partner deliverers, because a timetable is a plan and only the session record is a fact; the named partner contributor with a working email, because Appendix B demands contact data for industry partners under KPI 3.3 and a clinician who delivered one session two years ago is not traceable afterwards; and the debrief quality record and the learner feedback with its dates, because both are moment-in-time instruments. The scenario version and the equipment sign-off can in principle be reconstructed, but only if the scenario library and the maintenance log are themselves kept, which is the same problem one level down.

Reproducibility test. There is no KPI value for a second analyst to reproduce from this workflow, which is what "no Program Code" means in practice. The equivalent question is whether a second analyst could, from session records alone, tell WF-03 how many contact hours of a given course were delivered by a named external partner. Today the answer is no, because simulation sessions are not currently recorded with an hours split or a named external deliverer. That is the capture defect this workflow closes, and it is the only one here with a point value attached.

8. Max-score design

What this workflow must do to contribute.

1. Stamp a Program Code on every session, so an institutional capability can reach a programme row. Owner: Simulation Lead.
2. Record actual contact hours with the IoL and partner split, every session. Owner: Data Steward.
3. Name every external contributor with a working email, before the session runs. Owner: Simulation Lead.
4. Version every scenario and record the reason for each change. Owner: Data Steward.
5. Refuse to run a session without a competent debriefer or serviceable equipment. Owner: Simulation Lead.
6. Retain session-level learner feedback as raw per-question data with dates. Owner: Data Steward.
7. Populate the facility and operations fields annually rather than leaving them null. Owner: Simulation Lead.

[REDESIGN] actions.

Sequencing note. R3 is the one entry here with a genuine and quantifiable OBEF consequence, and it is a timetabling decision rather than an investment. R1 and R2 make R3 provable. Everything else in this table is educational quality work that happens to leave usable evidence behind, which is the right order for a capability that has no KPI of its own.

9. Indirect strategy where data cannot be collected

Category 4 applies: the activity exists but is invisible. And the honest scale of the prize is modest.

Category 4, activity exists but is invisible. IoL runs simulation. Clinical colleagues from Dubai Health entities take part in it. Learners are assessed within it and rate it in their course evaluations. None of that reaches the framework as simulation, because simulation has no Program Code and no KPI. It reaches the framework only as an attribute of something else: contact hours inside a course that KPI 3.3 tests, an assessment that KPI 2.1's reviewers might open, a course evaluation score that KPI 2.6 aggregates, a facility count in an institutional template. The response is capture, and the capture has to attach itself to the course rather than to the simulation centre.

The size of the prize, stated plainly. Of the 14.0 percentage points this workflow is listed against, almost none of it is won here. KPI 2.1's 7.5 points are decided by WF-09 and by CAA reviewers; simulation improves the material they will see, by an amount nobody can quantify in advance. KPI 2.6's 2.5 points are decided by learners across every course, of which simulation is a part. Only KPI 3.3's 4.0 points have a mechanism this workflow can point at directly, and even there the claim is assembled in WF-03 and is capped by the 20% and 10-hour thresholds. A reasonable expectation is that excellent simulation practice is worth a fraction of a point of OBEF score and a great deal to the learners. Both halves of that sentence should appear in any paper that asks for simulation investment on OBEF grounds.

Why the workflow is still in the pack. Three reasons. It is the Channel C3 substrate for two KPIs that IoL cannot otherwise influence. It holds the institutional facility data that would otherwise be returned null. And equipment readiness, faculty preparation, debriefing quality assurance and scenario version control are genuine simulation workflow content that a department running simulation needs regardless of what any framework counts.

Category 3 does not apply and should not be claimed. There is no simulation KPI whose weight could be redistributed, so there is nothing to classify as absent. Any argument that simulation should be "recognised" by the framework belongs in feedback to MoHESR, not in a submission.

Boundary check. This workflow must never:

• record planned contact hours as actual hours in order to help a course clear the KPI 3.3 20% share or the 10-hour floor;
• aggregate hours across courses that are not in fact a single course, in order to clear the 10-hour floor;
• claim a partner contribution where the contributor is not named in the syllabus, not on the formal timetable or in the LMS, or not linked to a learning outcome or assessment, since ad-hoc and optional activity is expressly excluded;
• claim a session as co-delivered where the partner attended but did not lead, host or deliver it;
• present simulation activity as a programme-level KPI in its own right, since it carries no Program Code;
• run a session on equipment that has failed its readiness check, or with a debriefer who holds no recorded competence, in order to protect a delivery statistic;
• use a scenario across cohorts without version control and then present the resulting assessment as comparable;
• report facility fields that overstate what IoL actually has available to its learners.

10. Service standards

11. Records and evidence

Appendix B readiness. Today, IoL could most likely produce equipment records, scenario materials and a description of its facilities within 15 working days. It could not produce a contact-hour split attributing simulation delivery to named external partners, because that split is not recorded, and it could not produce raw per-question session feedback with dates unless WF-06's instrument already covers the session. Those two gaps are R1, R2 and R6, and they are the difference between simulation contributing to KPI 3.3 and simulation being invisible to it.

12. Risks and controls

13. Performance measures

The last-but-one row is the only measure in this table that maps to a point value. The rest describe whether the simulation programme is any good, which is the reason to run it.

14. Change control