13.4 Maintenance, Operations, and Problem-Trend Analysis
Key Takeaways
- Tasks C.5 and C.6 are the long phase: operate and upgrade the live system, then analyze error reports, help-desk logs, surveys, performance metrics, and network monitoring for problems and trends.
- An upgrade is not a weekend install. It is a C.5 event that still uses SDLC, C.2 change control, and a clinical impact note.
- Incident is the break in front of you; problem is the recurring cause. C.6 rewards coding tickets so you can see the second one.
- No single source is sufficient. A green network dashboard with angry surveys and a rising override rate is a trend, not “the system is fine.”
- Trends feed the backlog: break/fix, enhancement, or reopen analysis when workarounds prove the design was wrong. First productive use is when this clock starts.
13.4 Maintenance, Operations, and Problem-Trend Analysis
Quick Answer: Task C.5 is maintain—operate and upgrade the live system with owners, windows, and change control. Task C.6 is analyze problems and trends from error reports, help-desk logs, surveys, performance metrics, and network monitoring. First productive use is when this clock starts, not when the project ends.
Implementation (C.4) hands a running system to operations. CPHIMS will offer “the project is done at go-live.” That is the same trap as Chapter 10’s skipped maintenance phase. Patches, version upgrades, new interfaces, slow queries, angry surveys, and a weekly “make the tracker show boarding” request all live here. Domain 3 still owns them. Formal testing methodology is Chapter 14; user-satisfaction programs as a leadership KPI are Chapter 16. This section is the operational loop that keeps the system true and reads the smoke.
C.5 Operate
Operate means the system stays available, confidential, and usable for care on an ordinary Tuesday, not only on go-live weekend.
Operating work includes:
- Named application and technical owners (who is paged, who accepts an upgrade, who can say no).
- Service levels that match clinical criticality (Chapter 12 tiers): the EHR is not the warehouse.
- Access joiners, movers, leavers—still a control after hypercare (privacy detail is Chapter 14).
- Backup, restore tests, and vendor SLAs that someone actually reads.
- Patch and version cadence negotiated with clinical calendars, not only with the vendor’s Tuesday.
- Job scheduling, interface-engine watch, certificate expiry, license and capacity headroom.
- A known-error and workaround list so the help desk does not rediscover the same broken printer map every night.
Operations without owners becomes a ticket pile. Operations without a window calendar becomes unplanned downtime during med pass.
C.5 Upgrade
An upgrade is any vendor version, module pack, infrastructure move, or major content load that changes behavior clinicians already depend on. It is not “just vendor code.”
Treat upgrades as a compact SDLC plus C.2:
- Plan the clinical risk: which screens, interfaces, reports, and downtime procedures change.
- Analyze the release notes against local build (medication, identity, revenue, devices).
- Design the local configuration, communication, and test set—including regression of last quarter’s fixes.
- Implement in a window with training delta, command-style support if the risk is high, and a back-out.
- Maintain the new baseline: owners, monitoring, and a post-upgrade defect sweep.
A “silent” EHR or pump-library upgrade that no one analyzed is how BCMA and dose checks break on a Monday. Cloud SaaS does not erase C.5: it changes who clicks deploy and leaves you the clinical validation and the communication. If the vendor can push a change, your operating model needs a review window or an explicit accept-risk—not surprise.
C.6 Read more than one instrument
Task C.6 names five inputs. Use them as a panel, not as competing religions.
| Source | What it can show | What it hides if used alone |
|---|---|---|
| Error reports / application logs | Exceptions, interface NAKs, failed jobs, CDS firings and overrides | Patients who never clicked; “worked around” paths that generate no error |
| Help-desk logs | Volume, category, time-to-close, unit, shift, repeat callers | Uncoded “EHR broken” tickets; people who stopped calling |
| Surveys | Perceived usability, trust, training gaps, after-upgrade sentiment | Low response from nights; politeness bias; lag |
| Performance metrics | Response time, availability, batch window, print/scan success, override rate, turnaround | Averages that hide the 07:00 login storm or one slow clinic |
| Network monitoring | Loss, latency, wireless roaming, segment health, certificate and path failure | Application lock contention that looks like “the network” to users |
Incident is the interruption in front of you (pharmacy cannot verify, the WLAN dropped on 4 West). Problem is the recurring cause (a certificate that expires monthly, a wireless channel plan, a build that forces five extra clicks). C.6 is mostly problem work. If tickets are not coded by application, unit, and failure type, you cannot trend. “EHR slow” as a single category is not analysis.
Practices that show up on items:
- Pareto the top codes weekly during hypercare and monthly after. The fifth reprint of “wrong printer on 4 West” is a problem, not 40 incidents.
- Join sources. Rising override rate plus a survey that says “alerts are noise” plus no application error is a CDS design trend (Chapter 9), not a server outage.
- Segment. Night versus day, one site versus another, wireless versus wired. Averages lie.
- Close the loop. A trend becomes a C.2 change, a training fix, a vendor ticket, or a reopened analysis. A dashboard no one acts on is decoration.
- Watch for design failure wearing a ticket costume. A weekly request to “make the tracker show boarding” after an upgrade is a signal to reopen analysis (Chapter 10), not to keep patching a screen.
Network monitoring belongs here because clinicians experience slowness as “the EHR is down.” CPHIMS still wants you to disambiguate: packet loss on the clinical SSID is a network trend; a 12-second database wait is an application trend. You need both instruments. Declaring the system healthy because the WAN graph is green, while login surveys collapse and BCMA scan-fail ticks up, is a C.6 miss.
Scenarios and exam traps
Scenario — weekend upgrade. Leadership schedules a major EHR version as a technical weekend because “it is just vendor code.” Medication-reconciliation screens will change. C.5 says operate/upgrade still needs a clinical impact note, regression, a window, and support. A version number is not a completed maintenance event.
Scenario — hire more analysts. The help desk is drowning three months after go-live. Sponsors want ten more FTEs. No one has coded tickets. C.6 first: Pareto by application, unit, and shift. You may find one wireless closet, one mis-mapped printer fleet, and one training gap—not a permanent staffing crisis.
Scenario — green and angry. Network operations shows a clean backbone. Clinicians report 20-second chart opens at 07:00. Surveys tank. Application metrics show a login storm and a slow identity call. The trend is not “users resist change.” Correlate the panel before you buy more WAN.
Scenario — override creep. After a content load, dose-alert overrides jump from 40% to 78%. Error logs are quiet. That is a C.6 trend with a Chapter 9 action: alert governance, not a server reboot.
Watch these traps:
- Calling go-live the end of Domain 3.
- Upgrading without SDLC or change control.
- Uncoded tickets and “EHR slow” as a single bucket.
- Trusting one instrument (usually the green graph).
- Treating every ticket as an incident forever—never promoting a problem.
- Staffing or training your way around a design that the trend already disproved.
- Ignoring network monitoring, or blaming the network for an application wait.
Leadership schedules a major EHR version upgrade as a weekend technical install because “it is just vendor code.” Medication-reconciliation screens will change. How should C.5 treat the upgrade?
Three months after go-live the help desk is drowning. Tickets are mostly typed as “EHR broken.” Sponsors want ten more analysts immediately. What is the best C.6 move first?
Network operations reports a green backbone. Clinicians say charts take 20 seconds to open at 07:00, surveys collapse, and BCMA scan-fail ticks up. What is the CPHIMS-correct C.6 reading?