Testing, go-live and support, after the build

Before connecting it to anything else, an analyst checks that a newly built pain reassessment flowsheet row accepts only values from 0 to 10 and displays them correctly. This is:

1. regression testing
   Regression testing reruns earlier tests after a change to make sure existing functions still work; this row is newly built.
2. integration testing
   Integration testing checks data passing between components or systems, which the stem rules out ('before connecting it to anything else').
3. system testing
   System testing evaluates the whole application end to end against requirements, not a single row.
4. unit testing
   Unit testing checks a single component, here one flowsheet row's allowed values and display, in isolation before it is connected to anything else.

A hospital converts every unit and module from its legacy EHR to the new system on the same day. Compared with other go-live strategies, this approach:

1. needs fewer support staff because training is shared
   Big bang needs the most at-the-elbow support, because every unit goes live at the same time.
2. lets staff compare old and new outputs side by side
   Comparing outputs side by side requires keeping the legacy system running, which a single-day cutover ends.
3. shortens the transition but concentrates risk on one day
   A big-bang cutover ends the transition quickly with no period of running two systems, but every unit's problems surface at once, which demands heavy support.
4. allows lessons from early units to improve later ones
   Learning from early units is the advantage of a phased or pilot rollout, not a single-day cutover.

A nurse submits a help desk ticket asking for a new column on the worklist. The worklist works exactly as designed and approved. This ticket should be handled as:

1. a tier-1 incident to resolve
   An incident is an unplanned interruption or loss of service; nothing is broken here.
2. a defect for the next patch
   A defect is behavior that differs from the approved design; the worklist works exactly as designed.
3. an enhancement request
   A request for new functionality in a system that works as designed is an enhancement, routed through change governance for prioritization.
4. a user error to close
   Closing it as user error dismisses a legitimate request instead of sending it to governance.

To determine whether a redesigned admission navigator reduced nurses' documentation time, the best data source is:

1. a count of screens in the old and new navigators
   Fewer screens do not guarantee less time; screen count is a design feature, not an outcome.
2. the vendor's benchmark data for the navigator
   Vendor benchmarks come from other organizations and cannot show what changed locally.
3. audit-log timestamps before and after the change
   Audit-log timestamps objectively record how long nurses spend in the navigator, so before-and-after comparisons measure real documentation time.
4. a survey of nurses' perceived time savings
   Perceived time is subjective and often differs from measured time; it complements, but cannot replace, objective data.

After a six-hour unplanned EHR outage ends, what must happen before the downtime event is closed?

1. back-entry of key paper documentation
   Recovery after downtime includes entering critical paper documentation, such as medications given and vital signs, so the electronic record is complete before the event is closed.
2. a full restore from the previous night's backup
   A restore is needed only if data were lost or corrupted; restoring old data after a normal outage would erase work done since.
3. retraining of all staff on downtime procedures
   Retraining may come out of the debrief, but it is not required before the event can be closed.
4. shredding of the paper downtime forms
   Downtime paper may be part of the legal record and must be kept or scanned, not destroyed.

After go-live, nurses report that the EHR slows sharply every day at 07:00 and 19:00. The informatics nurse's best first step is to:

1. retrain nurses to log in before shift change
   This shifts a system capacity problem onto users without knowing the cause.
2. ask IT to buy faster workstations for the units
   Buying faster workstations before diagnosing the problem is costly and may miss a server-side cause.
3. review system performance data for those times
   Checking performance monitoring for shift-change peaks finds the cause, such as concurrent logins, batch jobs, or capacity limits, before any fix is chosen.
4. request that the vendor install the next upgrade
   An upgrade is a guess without evidence and can add new problems.

Usage data show that prescribers uncheck a preselected daily CBC in the heart failure order set 85% of the time. The informatics nurse should:

1. review the default with the content owners
   An 85% uncheck rate shows the default does not match practice, so the clinical owners of the order set should review it and probably remove the preselection.
2. make the CBC required in the order set
   Forcing an order prescribers reject most of the time adds unneeded tests and workarounds.
3. retire the order set from use
   Retiring the whole order set throws away useful content to fix one default.
4. retrain prescribers to keep the CBC selected
   Usage data suggest the default is wrong, not that prescribers need training.

A hospital mirrors its EHR database in real time to a second data center. Why does it still need point-in-time backups?

1. Mirrored copies cannot be used after failover
   Using the mirror after failover is the whole purpose of mirroring.
2. Mirroring instantly copies corruption too
   Real-time mirroring replicates every change, including corruption, accidental deletion, or ransomware encryption, so point-in-time backups are needed to restore a clean earlier copy.
3. Backups restore faster than failover
   Failover to a mirror is usually much faster than restoring from backup; backups are kept for recovery points, not speed.
4. Mirroring cannot run over encrypted links
   Mirroring commonly runs over encrypted connections; encryption is no reason to keep backups.

During rollout of an electronic intake and output flowsheet, nurses document on both the paper form and the new system for two weeks. This strategy is:

1. pilot
   A pilot tries the new system in one area to decide on wider rollout; it does not require keeping the old form too.
2. phased
   A phased rollout moves units or modules over in stages; it does not mean double documentation.
3. big bang cutover
   A big-bang cutover stops the old process for everyone at once with no overlap.
4. parallel
   In a parallel conversion, the old and new systems run at the same time for a set period, here paper and electronic documentation for two weeks.

A pediatric dose-range check alerts above 40 mg/kg/day. The tester enters 39.9, 40, and 40.1 mg/kg/day to confirm the alert fires only above the limit. This is an example of:

1. load testing
   Load testing measures performance under heavy use, not the correctness of one rule.
2. boundary value testing
   Boundary value testing checks inputs just below, at, and just above a limit, where logic errors such as > versus >= tend to occur.
3. integration testing
   Integration testing checks data passing between systems, not a rule's threshold behavior.
4. regression testing
   Regression testing reruns existing tests after a change; choosing values around the limit is a test-design technique.

A new flowsheet labels a row 'OBS_RESP_ASSMT_TXT' instead of 'Respiratory assessment,' and nurses cannot find it. This design most directly violates the heuristic of:

1. flexibility and efficiency of use
   Flexibility and efficiency concern shortcuts and accelerators for expert users, not whether a label makes sense.
2. aesthetic and minimalist design
   Minimalist design removes irrelevant information; the row is relevant but labeled in jargon.
3. consistency and standards
   Consistency concerns the same words and actions meaning the same thing across screens; nothing suggests other rows use a different convention.
4. match with the real world
   Nielsen's match between system and the real world heuristic says screens should use the users' language, not internal database codes like OBS_RESP_ASSMT_TXT.

Patients using a telehealth app cannot tell whether their visit request was submitted, so many submit it two or three times. Which usability heuristic is MOST directly violated?

1. user control and freedom
   User control and freedom is about undo and an easy exit from unwanted states, not confirmation that an action worked.
2. visibility of system status
   Visibility of system status means users always know what the system is doing; without confirmation that the request went through, patients resubmit.
3. consistency and standards
   Consistency concerns predictable conventions across screens, not feedback after an action.
4. error prevention
   Error prevention is tempting because duplicate requests are an error, but they result from the missing status feedback, which is the heuristic actually broken.

The help desk has restored frozen workstations on one unit six times this month, closing each ticket. Finding and removing the underlying cause of the repeated failures is the goal of:

1. problem management
   Problem management looks for and removes the root cause of recurring incidents, unlike incident management, which restores service each time.
2. release management
   Release management plans and deploys builds and versions; it is not the process of diagnosing repeated failures.
3. incident management
   Incident management restores service as quickly as possible, which the help desk already did six times; that confusion is the trap.
4. change management
   Change management controls how changes are approved and released; it may carry out the fix but does not find the cause.

An unplanned EHR outage began 20 minutes ago and is expected to last 6 hours. Which communication mode should the informatics nurse use first to reach every clinical unit?

1. A flyer posted in each unit's break room
   A flyer is slow and passive and is not seen by staff caring for patients.
2. Overhead page and a call to each charge nurse
   In an unplanned outage, immediate synchronous channels that do not depend on the down system, such as an overhead page and direct calls to charge nurses, reach every unit at once.
3. An all-staff email that explains the downtime plan
   Email is slow, depends on network systems, and may not be read in time during a sudden outage.
4. A banner message on the EHR login screen
   A login banner suits scheduled downtime; during an unplanned outage the EHR may not be reachable at all.

During testing of an EHR upgrade that goes live in two days, the informatics nurse finds that the weight-based heparin calculator rounds doses incorrectly. The nurse should first:

1. escalate it through change control and ask to delay activation.
   A dosing defect in a high-alert drug two days before activation is a patient-safety risk that must be escalated through change control, with a hold on activation until it is fixed and retested.
2. correct the calculation logic directly in the production environment.
   Changing production directly bypasses testing and change control and can introduce new errors.
3. email nurses and pharmacists a warning to double-check heparin doses.
   A warning email shifts the burden to busy clinicians and leaves a known dosing defect in the system.
4. log the defect for the post-implementation optimization phase.
   Optimization is for improvements, not for a known safety defect in a high-alert medication.