13.2 Technical Change Management, Training, and Support
Key Takeaways
- Task C.2 is technical change management: request, assess, authorize, build in non-production, test, schedule, implement, and prove a rollback. It is not organizational change management (Domain 4 / Chapter 17).
- A production medication-library, interface, or identity change needs an RFC, an environment path, a back-out, and a named approver. A town hall is not a CAB.
- Task C.3 training methods are matched to the job: computer-based learning, classroom, train-the-trainer, and at-the-elbow support from superusers—not one lecture for every role.
- Superusers are a support model through hypercare, not a one-day trainer pool that returns to the floor with no protected time.
- Role-based competency in a training environment beats tip sheets in production. Training does not repair a design that failed the workflow.
13.2 Technical Change Management, Training, and Support
Quick Answer: Task C.2 is technical change management—the request, authorization, environment, test, and rollback path that keeps production from becoming a hallway edit. Task C.3 is training and support: computer-based learning, classroom, train-the-trainer, and at-the-elbow superusers. Do not confuse C.2 with organizational change management (Chapter 17).
After C.1 names a winner, two different “change” problems appear. One is how a bit, a build, or a library enters production without harming a med pass. That is C.2. The other is how people learn the new work and get help when they are stuck. That is C.3. Domain 4 will later ask how you sponsor, communicate, and handle resistance. This section is the technical and instructional control. Mix the two on a stem and you will pick the town hall when the exam wanted the change-advisory board.
Technical change management is not organizational change
Technical change management (also called change control) is the disciplined path that protects the live system:
- Someone files a request for change (RFC) with what will change, why, risk, affected systems, and a back-out.
- Impact assessment covers interfaces, identity, downtime, privacy, and who must be in the room (pharmacy for a dose-range table; HIM for a legal-hold field).
- Authorization is a change advisory / change-control board (CAB) or an emergency path with a named after-the-fact review—not a chat message.
- Build and unit test happen in non-production. Promotion follows the environment chain (development → test/validation → production).
- Implementation is scheduled, communicated to operations, and watched. Rollback is a rehearsed step, not a hope.
- Evidence is kept: who approved, what was tested, what was released, what was backed out.
Organizational change management is how people adopt new work: sponsorship, communication, resistance, workflow redesign, and culture. That is Domain 4 task territory (Chapter 17). A perfectly authorized patch can still fail adoption. A brilliant town hall does not authorize a production medication-library edit.
Exam language to keep separate:
| Cue in the stem | CPHIMS home | First move |
|---|---|---|
| Production, RFC, CAB, freeze, back-out, version, environment, emergency change | C.2 technical change | Stop the hallway edit; open an RFC |
| Superuser, CBT, classroom, elbow support, tip sheet, competency | C.3 training and support | Match method to role and risk |
| Sponsor, resistance, coalition, communication plan, culture | Domain 4 / Chapter 17 | Do not pick CAB language |
A standard change is pre-authorized, low-risk, and runbooked (password reset pattern, known printer mapping). A normal change needs assessment and a window. An emergency change (broken allergy check at 02:00) is still logged, still has a back-out if possible, and is reviewed after. “Emergency” is not a synonym for “no record.”
Change freeze before a survey, a holiday, or go-live is a C.2 tool. Exceptions still go through the emergency path. Configuration management (knowing what is in production) is how you even write the RFC. If you cannot name the current dose-range table version, you cannot change it safely.
Training methods C.3 expects you to name
C.3’s official examples are computer-based learning (CBT), classroom training, train-the-trainer, and at-the-elbow support from superusers. The exam scores the match, not a claim that one method is always best.
| Method | What it is good for | What it cannot do |
|---|---|---|
| CBT / e-learning | Standard navigation, policy acknowledgments, large geographically spread staff, just-in-time refreshers, night-shift access | Replace supervised practice on a high-risk workflow; prove glove-and-scanner competence |
| Classroom / virtual classroom | Shared mental model, facilitated practice, questions in a group, role-play of a new huddle | Scale to every night-shift nurse the week of go-live if you only booked day-shift rooms |
| Train-the-trainer (TTT) | Building a local faculty who know your build, not the vendor starter pack | Work if trainers have no protected time, no competency check, or a different build than production |
| At-the-elbow superusers | Live support in the first hours and days; catching workarounds; translating the classroom to this unit’s rooms | Substitute for a missing design; superusers who are not backfilled become unpaid help-desk staff |
Design rules:
- Role-based. A registrar, a hospitalist, a pharmacist, and a transporter do not share a four-hour “EHR class.”
- Competency, not attendance. High-risk roles (BCMA, transfusion, chemotherapy, charge capture) need a demonstrated check in a training environment that looks like production.
- Timing. Train too early and the skill decays. Train only on go-live morning and you invent shadow charts. Just-in-time plus a refresh path is the usual design.
- Environment. Training in production, or in a domain that does not match the go-live build, teaches the wrong clicks.
- Coverage. Night, weekend, per-diem, and medical-staff affiliates are in scope. A Tuesday 10:00 classroom is not a plan.
- Training does not fix design. If usability testing failed, reopen design (Chapter 10). More CBT will not make an unusable allergy interrupt safe.
Superusers and support
A superuser is a peer with extra training, protected time, and a path into the command center or help desk. Superusers are not “whoever volunteered after staff meeting.”
C.3 pairs training with support:
- At-the-elbow during go-live and hypercare (often 24×7 for a defined window on clinical units).
- A tiered help desk that can distinguish a how-to from a broken interface, and that codes tickets so C.6 can later see trends.
- Job aids that match the live build (downtime packets, BCMA exception card)—versioned, not a PDF lost in email.
- An escalation tree: superuser → informatics / application on-call → vendor / command center. Do not make the house supervisor guess.
When hypercare ends, superusers need a residual role (office hours, huddle, enhancement intake) or the organization silently reverts to workarounds. That handoff is already a C.5 maintenance problem; design it here so support does not vanish on day 15.
Scenarios and exam traps
Scenario — hallway library edit. A pharmacist messages an analyst at 21:00: “just add this concentration so the OR can start.” The analyst has production access. C.2 says no: this is a medication-safety change. Open an RFC, assess pump-library and eMAR impact, test in non-production, authorize (emergency path if a case is on the table), and keep a back-out. A town hall next week does not authorize tonight’s edit.
Scenario — one classroom for 400 nurses. Education books a single day-shift auditorium two months before go-live and calls training complete. Night shift, per-diem staff, and medical assistants are uncovered. C.3 wants a mix: CBT for navigation, TTT for unit faculty, scheduled classroom or skills labs for high-risk roles, and at-the-elbow superusers at go-live. Attendance at one lecture is not competency.
Scenario — superusers as free labor. Units name superusers, send them to a vendor class, then schedule them as regular staff with a “please help your neighbors” note. They cannot leave the assignment. At-the-elbow support requires backfill and a shift pattern. Otherwise you have unpaid tier-1 support and no one watching patients.
Scenario — org-change answer on a C.2 stem. Leadership wants a communication campaign because “people fear the upgrade.” The stem is about a production interface move this weekend. Pick the freeze, the CAB, the integrated test, and the rollback. Save the campaign for Chapter 17.
Watch these traps:
- Treating a chat, a town hall, or a sponsor email as change authorization.
- Building in production “because it is faster.”
- Calling every after-hours edit an emergency with no record.
- One classroom, one tip sheet, no night-shift path.
- Superusers without protected time.
- Training through a failed design.
- Answering a C.2 stem with Kotter or ADKAR language.
C.2 keeps the system from changing in the dark. C.3 keeps people from guessing in the dark. Section 13.3 then asks whether the implementation still fits scope, schedule, budget, and quality when the date is printed on a banner.
A surgeon asks an analyst to “just add” a new medication concentration in the production pharmacy library before a 06:00 case. Leadership offers a town hall next week to “manage the change.” What is the CPHIMS-correct C.2 move?
Four hundred nurses, including nights and per-diem staff, must be ready for BCMA go-live in six weeks. Education has booked one Tuesday classroom. What C.3 design is most appropriate?
Units name superusers, send them to a vendor class, then schedule them as regular staff with no backfill. On go-live morning they cannot leave their assignments. What support method failed?