Hospital Information Systems

Chapter 10
Project Management, Change Leadership and Adoption

Post Graduate Program in Health Care Management
Hospital Information Systems   •   Post Graduate

Project Management, Change Leadership and Adoption

Introduction

Hospital information system (HIS) programmes are not merely technology installations. They are organisational transformations that alter clinical work, managerial control, professional roles, information flows, accountability and patient experience. A technically successful system may still fail if clinicians avoid it, if workflows become unsafe, if data quality deteriorates, or if expected benefits are not realised. Conversely, a project that experiences technical difficulties may still create substantial value when governance, learning and adaptation are strong.

Project management provides the discipline for defining and delivering a change within agreed constraints. Change leadership addresses the human and institutional processes through which people understand, accept, enact and sustain the new way of working. Adoption concerns actual use, appropriate use and continued use. Benefits realisation connects implementation activity to measurable improvements in quality, efficiency, safety, experience and strategic performance.

In healthcare, these concerns are inseparable. A new electronic medication administration system, for example, affects prescribing, pharmacy verification, nursing documentation, barcode scanning, inventory, clinical decision support, patient identification and reporting. It must therefore be managed as a socio-technical intervention rather than as an isolated software project.

Learning objectives

By the end of this chapter, the learner should be able to:

  1. Distinguish project management, programme management, change management, change leadership and adoption.
  2. Develop an integrated scope, schedule, cost, risk and quality approach for an HIS initiative.
  3. Apply stakeholder, communication and resistance-management frameworks in a clinical setting.
  4. Design governance structures that support clinical engagement, safety and accountability.
  5. Assess usability, digital competence, adoption and benefits realisation using appropriate indicators.
  6. Evaluate ethical, regulatory and organisational risks associated with HIS transformation.
  7. Critically interpret an applied HIS implementation case and propose an improvement strategy.

1. The HIS initiative as a socio-technical project

A project is a temporary endeavour undertaken to create a unique product, service or result. An HIS project may deliver a new electronic health record, replace a legacy laboratory system, integrate regional data, deploy patient portals, or introduce analytics and artificial intelligence. The project has a defined start and completion point, but its outcomes depend on continuing operational work after go-live.

A programme coordinates related projects to achieve benefits that would not be obtained by managing them separately. For example, a digital hospital programme may include electronic prescribing, interoperability, infrastructure renewal, workforce training and data-governance projects. Portfolio management determines which investments best support organisational strategy and risk appetite.

The following distinction is important:

ConceptPrimary concernTypical success question
Project managementDelivery of agreed outputsWas the system delivered within acceptable scope, time, cost and quality?
Change managementTransition of people and processesAre users prepared and supported to work differently?
Change leadershipDirection, meaning and mobilisationWhy should the organisation change, and who will sustain it?
AdoptionBehaviour in practiceAre intended users using the system correctly and consistently?
Benefits realisationOrganisational valueHas the investment produced measurable improvements?

The traditional “iron triangle” of scope, schedule and cost remains useful, but it is insufficient in healthcare. Quality, safety, usability, equity, interoperability, workforce burden and benefits must also be treated as constraints or success dimensions. Accelerating deployment by reducing testing or training may satisfy a schedule target while increasing clinical risk.

1.1 Predictive, adaptive and hybrid approaches

Predictive approaches define requirements and plans early, then control deviations through formal change management. They are suitable where regulatory documentation, infrastructure dependencies and safety assurance require stability. Adaptive approaches use short cycles, frequent feedback and evolving requirements. They are useful for user-interface design, dashboards and workflow refinement. Hybrid delivery combines predictive governance with iterative configuration and testing.

A hospital may use a predictive approach for procurement, cybersecurity accreditation and data migration, while using iterative cycles for clinical forms and decision-support alerts. The choice should follow uncertainty, risk and the cost of late change—not fashion.

2. Governance and accountability

Effective governance establishes who decides, who advises, who delivers and who is accountable for risk. A typical structure includes:

  • Executive sponsor: owns the strategic case, resolves major barriers and secures resources.
  • Steering committee: authorises scope, funding, major risks and stage transitions.
  • Programme or project manager: integrates plans, dependencies, resources, risks and reporting.
  • Clinical safety officer: coordinates hazard identification, safety cases, incident learning and clinical assurance.
  • Product or service owner: prioritises requirements and represents operational value.
  • Clinical and operational leads: translate work practices into requirements and validate workflows.
  • Technical and data leads: oversee architecture, integration, migration, performance and security.
  • Change and learning leads: coordinate communication, training, readiness and adoption.
  • Super users or clinical champions: provide local support and feedback.

A responsibility assignment matrix, often expressed as RACI, clarifies whether a participant is Responsible, Accountable, Consulted or Informed. RACI is a governance aid, not a substitute for judgement. Each critical deliverable should have one accountable owner, even if many people contribute.

Stage gates can be used at initiation, design approval, build completion, testing, go-live readiness and post-implementation review. A gate should examine evidence, not simply confirm that activities occurred. For example, “training delivered” is weaker evidence than “all high-risk roles demonstrated competence in medication reconciliation and downtime procedures.”

3. Managing scope, requirements and quality

Scope defines what the project will and will not deliver. Poor scope control produces scope creep, which consumes capacity and obscures accountability. Excessive restriction, however, can create a system that is formally on scope but clinically unusable.

A sound scope statement identifies:

  1. intended outcomes and user groups;
  2. included functions, sites, interfaces and data domains;
  3. exclusions and assumptions;
  4. dependencies and acceptance criteria;
  5. regulatory, safety, privacy and interoperability obligations.

Requirements should be elicited from observed work as well as interviews. Shadowing, process mapping, clinical simulation, review of incident reports and analysis of existing data can reveal workarounds that users may not mention in meetings. Requirements should be prioritised by patient-safety impact, legal necessity, strategic value, workflow importance and implementation effort.

A useful acceptance criterion is observable and testable: “A ward nurse can locate the current allergy status, record a verified allergy and receive an understandable alert within the medication workflow.” “The system must be user-friendly” is not sufficiently precise unless usability dimensions and evaluation methods are specified.

Quality assurance is preventive: standards, design reviews, coding practices, configuration control and test plans. Quality control is evaluative: inspections, test execution, defect management and acceptance decisions. In HIS projects, testing should include unit, integration, performance, security, usability, accessibility, migration, clinical-scenario and downtime testing. End-to-end testing is essential because a defect may arise at the interaction of otherwise functional systems.

4. Schedule, cost and risk management

The schedule should represent dependencies rather than merely list dates. A work breakdown structure decomposes deliverables into manageable work packages. Network planning identifies tasks that constrain the completion date. The critical path is the sequence of dependent activities with the least scheduling flexibility; delay in a critical-path activity can delay the project unless corrective action is taken.

Milestones should include decisions and evidence, not only technical events. Examples are approval of the future-state workflow, completion of data-quality remediation, clinical safety sign-off and successful disaster-recovery rehearsal.

Cost planning should include more than licensing and implementation fees. Relevant categories include infrastructure, integration, data cleansing, internal staff time, backfill for clinical participants, training, temporary productivity loss, cybersecurity, support, benefits measurement and recurrent maintenance. Total cost of ownership is particularly important when a low initial price creates high long-term configuration or support costs.

For financial appraisal, a simple return-on-investment measure may be used:

ROI = (Benefits − Costs) ÷ Costs × 100%

Here, benefits and costs must be measured over the same period and expressed in the same monetary units. The calculation is meaningful only when the organisation defines which benefits are attributable to the project and whether costs include implementation and recurrent expenditure. Non-monetary benefits such as reduced medication harm should not be ignored merely because they are difficult to price.

Risk is uncertainty that may affect objectives. A risk register should record the cause, event, consequence, probability, impact, owner, response and review date. A qualitative risk score is often calculated as:

Risk score = Probability × Impact

Probability and impact must use an explicitly defined ordinal scale, such as 1–5. The result is a prioritisation aid, not a statistical probability of harm. Multiplying ordinal categories assumes that the scale is suitable for ranking; it does not establish precise ratios. High-scoring risks require proportionate treatment, such as avoidance, reduction, transfer or acceptance with contingency.

For project control, earned value analysis can integrate scope, schedule and cost. Let PV be planned value, EV earned value and AC actual cost, all measured in the same currency at a specified status date:

CV = EV − AC
SV = EV − PV
CPI = EV ÷ AC
SPI = EV ÷ PV

Cost variance (CV) and schedule variance (SV) are expressed in monetary units. A positive CV indicates that earned value exceeds actual cost; a positive SV indicates that earned value exceeds planned value. The cost performance index (CPI) and schedule performance index (SPI) are dimensionless. Values above 1.00 indicate favourable performance under the model. Earned value does not measure clinical quality or safety, so it must be interpreted alongside those indicators.

5. Stakeholder engagement and clinical partnership

Stakeholders include patients, families, clinicians, managers, administrators, suppliers, regulators, professional bodies, unions, information-governance officers and communities affected by the system. Stakeholder analysis should consider power, interest, impact, expertise, legitimacy and potential for support or resistance.

Clinical engagement is not achieved by inviting clinicians to a late demonstration. It requires participation at problem definition, workflow design, prioritisation, testing, training, go-live and evaluation. Clinicians should have protected time and clear authority. Otherwise, “engagement” becomes unpaid consultation that is dominated by operational pressure.

Clinical champions are credible translators between project teams and professional communities. They should not be used to suppress legitimate concerns. Their role is to surface safety issues, demonstrate realistic use, support peers and contribute to local adaptation.

Patient and public involvement is also important. Patient representatives can identify accessibility, privacy, language, consent and continuity-of-care concerns that are invisible to internal teams. Participation should be inclusive and supported, rather than symbolic.

6. Change leadership and resistance

Change management addresses transition, whereas change leadership creates meaning, legitimacy and momentum. Several complementary models are useful.

Lewin’s model describes unfreezing existing assumptions and routines, moving toward a new state and refreezing effective practices. Its value is conceptual, although real healthcare change is rarely a simple linear sequence. Kotter’s framework emphasises urgency, a guiding coalition, vision, communication, removal of barriers, short-term wins, consolidation and institutionalisation. The ADKAR model focuses on individual outcomes: Awareness, Desire, Knowledge, Ability and Reinforcement.

These models should not be applied mechanically. Resistance may represent fear, habit, workload, professional identity, lack of trust, poor system design or a valid warning about safety. Labelling all dissent as resistance is ethically and operationally dangerous. A more useful classification distinguishes:

  • Information resistance: people do not understand the purpose or process.
  • Capability resistance: people lack time, skills, access or confidence.
  • Value resistance: the change conflicts with professional or organisational values.
  • Design resistance: the proposed workflow is genuinely inferior or unsafe.
  • Political resistance: the change redistributes authority, visibility or resources.

Responses should match the cause. Information gaps require transparent communication; capability gaps require training and support; design resistance requires redesign; political concerns require explicit governance and negotiation.

Communication should be two-way, role-specific and repeated. A communication plan identifies the audience, message, sender, channel, timing, feedback mechanism and evidence of understanding. Executives may need the strategic case and risk profile; ward staff need workflow consequences, training arrangements and escalation routes. Communication should acknowledge uncertainty rather than promise that disruption will be absent.

7. Digital competence, training and adoption

Training is one component of capability, not a guarantee of competence. A robust learning strategy begins with a role-based competency analysis. It distinguishes basic navigation from high-risk tasks such as medication administration, result acknowledgment, privacy protection, clinical documentation and downtime operation.

Effective methods include simulation using realistic cases, supervised practice, peer support, brief just-in-time resources and scenario-based assessment. Training environments should reflect actual configuration. If the system changes substantially after training, competence must be reassessed.

Adoption has several dimensions:

  • Reach: proportion of intended users who access the system.
  • Frequency: how often relevant functions are used.
  • Depth: whether users employ the required capabilities.
  • Fidelity: whether use follows safe and intended processes.
  • Persistence: whether appropriate use continues over time.
  • Equity: whether adoption is comparable across roles, sites and user groups.

Usage logs are useful but incomplete. High login counts may reflect mandatory access without meaningful use. Low use may be appropriate for a role. Quantitative data should therefore be combined with observation, interviews, usability testing, help-desk data, incident reports and workflow measures.

Usability concerns effectiveness, efficiency, learnability, memorability, error tolerance and satisfaction in a specified context. Clinical usability must be assessed with representative users performing realistic tasks, not only with technical experts reviewing screens. A system that saves keystrokes but obscures critical information may be efficient in a narrow sense yet unsafe overall.

8. Measuring benefits and performance

Benefits should be defined before implementation and assigned to accountable owners. A benefits map links enabling changes to intermediate outcomes and strategic benefits. For example:

New medication workflow → more complete medication reconciliation → fewer discrepancies at admission → reduced preventable harm.

Measures should include baseline, target, data source, measurement frequency, owner and confounding factors. A balanced benefits scorecard may include:

DimensionIllustrative measures
Safetymedication discrepancies, alert overrides, identification errors
Qualitycompleteness and timeliness of documentation, guideline adherence
Efficiencyturnaround time, duplicate tests, administrative workload
Experiencepatient-reported experience, clinician burden, help-desk themes
Adoptionactive users, task completion, appropriate feature use
Equityperformance by language, age, disability, location or socioeconomic group
Financeavoidable costs, productivity, total cost of ownership

A before-and-after comparison is easy to perform but vulnerable to seasonal trends, staffing changes and regression to the mean. Where feasible, a difference-in-differences design compares change over time in an intervention group with change in a suitable comparison group:

Estimated effect = (Y₁,after − Y₁,before) − (Y₀,after − Y₀,before)

Here, Y₁ represents the intervention group and Y₀ the comparison group. The approach assumes that, without the intervention, both groups would have followed parallel trends. This assumption must be examined rather than assumed. Operational evaluation should combine quantitative analysis with qualitative explanation of how and why outcomes changed.

Benefits realisation continues after go-live. A project can close when deliverables are accepted, while benefits remain the responsibility of operational owners. Post-implementation reviews should examine intended and unintended consequences, technical debt, workarounds, inequities and whether further optimisation is justified.

9. Safety, ethics, governance and regulation

HIS change can create hazards through incorrect configuration, ambiguous alerts, poor data migration, identity mismatches, interface failure, automation bias and inaccessible design. Clinical safety should use structured hazard analysis, traceability from requirement to test, incident reporting and explicit residual-risk decisions.

Privacy and security principles include purpose limitation, data minimisation, access control, authentication, auditability, secure data exchange, retention control and breach response. Access should be based on legitimate need, not convenience. Secondary use of data for analytics or artificial intelligence requires lawful authority, governance, transparency and attention to re-identification risk.

Ethical concerns include autonomy, confidentiality, fairness, explainability, accountability and distributive justice. Digital exclusion may arise when portals or automated services assume reliable connectivity, literacy, language proficiency or disability-free access. Human alternatives and reasonable accommodations are part of responsible adoption.

Artificial intelligence can support documentation, triage, coding, forecasting or decision support, but it introduces risks of bias, hallucination, opacity, automation complacency and model drift. AI-enabled functions require defined human oversight, performance monitoring across relevant populations, escalation mechanisms and clear accountability. “The algorithm recommended it” is not an acceptable transfer of clinical responsibility.

10. Applied case: Riverside Health Network

This is an illustrative fictional case.

Background

Riverside Health Network, comprising one hospital and 24 primary-care practices, introduced an integrated electronic medication-management platform. The strategic objectives were to improve medication reconciliation, reduce transcription, support pharmacy inventory and provide a shared medication list.

Problem

The programme was six months behind schedule and 18% above its approved implementation budget. Nurses reported that barcode scanning interrupted medication rounds, pharmacists found frequent duplicate records, and physicians received excessive alerts. Staff engagement surveys showed that many users viewed the project as an administrative burden. The steering committee initially proposed accelerating go-live to recover the schedule.

Analysis

A rapid review found that the baseline workflow had never been mapped across inpatient and primary-care settings. Requirements had been gathered mainly from department managers. Training completion was reported at 92%, but assessment measured attendance rather than competence. Data migration had transferred historic medication entries without adequate reconciliation. The risk register listed “user resistance” but did not identify alert burden, patient-identification failure or insufficient clinical backfill as specific risks.

The project team separated delivery problems from adoption problems. The schedule variance was real, but accelerating without redesign would increase clinical risk. A clinical safety review identified three high-priority hazards: duplicate medications, interrupted medication rounds and ambiguous allergy displays.

Approach and solution

The sponsor authorised a six-week recovery phase. A multidisciplinary design group observed medication rounds, reviewed incident reports and conducted simulations with nurses, pharmacists, physicians and patients. The team:

  1. removed low-value alerts and required a clinical rationale for retained high-severity alerts;
  2. redesigned the allergy and medication-history display;
  3. introduced a reconciliation queue for uncertain migrated records;
  4. tested barcode scanning under realistic interruptions and network downtime;
  5. provided protected time for ward champions and pharmacy reviewers;
  6. replaced attendance-based training with role-specific simulation assessment;
  7. established daily go-live huddles and a rapid safety-escalation route;
  8. published a benefits dashboard with baseline and target measures.

The revised plan delayed the hospital launch by four weeks but retained the primary-care pilot. The steering committee accepted the delay because the evidence showed that readiness and safety had improved.

Outcome

Three months after hospital go-live, medication-reconciliation completion increased from 61% to 88%, while duplicate active medication records fell by 37%. The proportion of high-severity alerts overridden without documented review decreased. Initial documentation time increased, but returned toward baseline after workflow refinement and peer support. Clinician confidence improved, although night-shift adoption remained lower than daytime adoption. The network therefore extended support during nights and added an equity review of access to training.

The programme did not claim that all improvements were caused by the platform. A concurrent pharmacy staffing increase and revised reconciliation policy were recorded as possible contributors. The benefits owner continued measurement at six and twelve months.

Learning points

The case demonstrates that schedule recovery is not the same as value recovery. Clinical engagement must influence design, not merely endorse it. Training attendance is an activity measure, whereas demonstrated competence and safe use are outcome measures. Data migration and alert design are clinical-safety issues. Finally, delaying a release can be a sign of strong governance when evidence shows that the original plan is unsafe or unlikely to produce benefits.

11. Contemporary developments and best practice

HIS projects increasingly involve cloud services, application programming interfaces, patient-generated data, mobile workflows, remote care and AI-enabled functions. These developments increase the importance of interoperability, identity management, vendor governance, data provenance and continuous monitoring. The boundary between project and operations is also becoming less distinct: systems are configured continuously rather than delivered once and frozen.

Best practice is therefore iterative and evidence-led:

  • begin with a measurable clinical and organisational problem;
  • establish accountable sponsorship and clinical safety authority;
  • define scope, outcomes, exclusions and decision rights;
  • involve representative users and patients from the outset;
  • design for workflow, accessibility, interoperability and downtime;
  • maintain an integrated risk, issue, dependency and decision log;
  • test with realistic clinical scenarios and migrated data;
  • assess competence, not merely training attendance;
  • communicate honestly, repeatedly and through trusted channels;
  • monitor adoption, safety, burden and equity after go-live;
  • assign benefits to operational owners and review them over time;
  • treat feedback and incidents as inputs to learning, not as threats to project reputation.

Challenges and limitations

No framework eliminates uncertainty. Healthcare organisations contain competing professional cultures, complex dependencies and changing priorities. Benefits may be delayed or difficult to attribute. Performance indicators can encourage gaming or narrow attention to what is easy to count. Stakeholder engagement can become tokenistic, while champions may experience burnout. Iterative delivery can generate configuration inconsistency if architectural and safety controls are weak. Predictive planning can create false confidence when requirements are poorly understood.

Managers should therefore use frameworks as thinking tools. They must examine assumptions, seek disconfirming evidence, protect psychological safety and remain prepared to revise the plan. The ethical test is not whether the project team meets its original baseline, but whether the resulting service is safe, useful, equitable and sustainable.

Chapter Summary

HIS implementation is a socio-technical transformation requiring integrated project management, change leadership and benefits governance. Project management controls scope, schedule, cost, quality, risk and dependencies; change management supports transition; change leadership creates meaning, legitimacy and mobilisation; adoption examines actual and appropriate use; and benefits realisation connects the intervention to measurable value.

Effective implementation requires accountable governance, clinical and patient partnership, realistic workflow analysis, role-based competence development, iterative testing and transparent communication. Resistance should be interpreted rather than suppressed because it may reveal capability gaps, political concerns or genuine design hazards. Usability, adoption and benefits must be assessed with mixed evidence, including system data, observation, qualitative feedback, safety indicators and equity analysis. Ethical implementation protects privacy, security, autonomy, fairness and clinical accountability. Strong governance may require delaying delivery when readiness or safety evidence is inadequate.

Key Terms

Project management: Coordinating temporary work to deliver defined outputs and outcomes.

Programme management: Coordinating related projects to achieve broader benefits.

Change management: Structured support for organisational and individual transition.

Change leadership: Mobilising people around a meaningful direction and sustained change.

Adoption: Actual, appropriate and continuing use of an implemented system.

Benefits realisation: Planning, measuring and sustaining value created by an investment.

Scope: The boundaries of what a project includes and excludes.

Acceptance criterion: A testable condition used to determine whether a deliverable is acceptable.

Critical path: The dependency sequence that constrains the earliest project completion.

Risk register: A controlled record of risks, causes, consequences, responses and owners.

Clinical champion: A trusted practitioner who translates between clinical communities and the project.

Usability: The effectiveness, efficiency, learnability and satisfaction of use in context.

Digital competence: The knowledge, skills and judgement required for safe digital work.

Benefits owner: The person accountable for achieving and measuring a specified benefit.

Clinical safety case: Structured evidence that a digital change is acceptably safe for intended use.

Scope creep: Uncontrolled expansion of requirements or deliverables.

Earned value: The authorised value of work actually completed.

Stakeholder: A person or group that affects, is affected by or has an interest in the change.

Automation bias: Undue reliance on an automated recommendation or output.

Review Questions

Short Answer Questions

  1. Distinguish project management from change leadership in an HIS implementation.
  2. What is the purpose of a stage gate?
  3. Why is training attendance an inadequate measure of competence?
  4. Identify four dimensions of HIS adoption.
  5. Why should clinical resistance not automatically be treated as a problem to suppress?

Long Answer Questions

  1. Explain how scope, schedule, cost, quality and safety should be integrated in an HIS project.
  2. Compare predictive, adaptive and hybrid approaches and recommend circumstances for each.
  3. Discuss the role of clinical champions, patients and executive sponsors in HIS governance.
  4. Explain how benefits realisation differs from project completion and propose a benefits scorecard.
  5. Evaluate the ethical and regulatory considerations of introducing AI-enabled decision support.

Analytical / Application Questions

  1. A hospital is on schedule but has low usability-test performance and incomplete downtime procedures. Should it proceed to go-live? Develop a governance recommendation and justify it.
  2. An electronic prescribing system has high login rates but frequent workarounds and alert overrides. Design a mixed-method evaluation to distinguish adoption from safe, effective use.
  3. A project has PV = $800,000, EV = $720,000 and AC = $900,000 at the reporting date. Calculate CV, SV, CPI and SPI, interpret the results, and explain why these indicators alone cannot determine clinical success.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes change leadership from project management?

A. Change leadership focuses only on software configuration.

B. Change leadership creates meaning, legitimacy and mobilisation for sustained change.

C. Change leadership replaces the need for governance.

D. Change leadership measures only project expenditure.

Correct Answer: B. Change leadership creates meaning, legitimacy and mobilisation for sustained change.

Question 2

Which item is the strongest example of an acceptance criterion?

A. The system should be modern.

B. Users should like the system.

C. A nurse can record a verified allergy within the medication workflow and receive an understandable alert.

D. The vendor will provide excellent support.

Correct Answer: C. A nurse can record a verified allergy within the medication workflow and receive an understandable alert.

Question 3

If EV = $720,000 and AC = $900,000, what is the cost variance?

A. $180,000 favourable

B. $180,000 unfavourable

C. $1,620,000 favourable

D. 0.80% unfavourable

Correct Answer: B. $180,000 unfavourable

Question 4

A risk score calculated as Probability × Impact using a 1–5 ordinal scale is best understood as:

A. A precise probability of patient harm

B. A prioritisation aid

C. A legally binding financial estimate

D. A measure of system usability

Correct Answer: B. A prioritisation aid

Question 5

Which response best addresses design resistance?

A. Increase generic email frequency only.

B. Ignore the concern until after go-live.

C. Investigate the workflow and redesign the system if evidence supports the concern.

D. Remove the concerned users from testing.

Correct Answer: C. Investigate the workflow and redesign the system if evidence supports the concern.

Question 6

Which measure most directly assesses competence rather than training activity?

A. Percentage of staff invited to training

B. Number of training sessions scheduled

C. Percentage of users demonstrating safe medication reconciliation in simulation

D. Number of slides in the training presentation

Correct Answer: C. Percentage of users demonstrating safe medication reconciliation in simulation

Question 7

What is a limitation of using login counts as the sole adoption measure?

A. Login counts can never be collected.

B. High login counts may not indicate meaningful or safe use.

C. Login counts measure clinical outcomes directly.

D. Login counts are always biased downward.

Correct Answer: B. High login counts may not indicate meaningful or safe use.

Question 8

In earned value analysis, a schedule performance index below 1.00 generally indicates that:

A. Actual cost is below budget.

B. Earned progress is less than planned progress.

C. The project has achieved all benefits.

D. Clinical quality is above target.

Correct Answer: B. Earned progress is less than planned progress.

Question 9

Which governance decision is most defensible when high-risk clinical hazards remain unresolved before go-live?

A. Proceed because the original date cannot change.

B. Remove the hazards from the risk register.

C. Escalate the evidence and delay or restrict deployment until risk is acceptably controlled.

D. Ask users to accept personal responsibility for the hazards.

Correct Answer: C. Escalate the evidence and delay or restrict deployment until risk is acceptably controlled.

Question 10

Which principle is most relevant when evaluating an AI-enabled clinical decision-support function?

A. Automation removes the need for human accountability.

B. Performance should be monitored across relevant populations with defined human oversight.

C. A vendor claim is sufficient evidence of safety.

D. The model should never be changed after deployment.

Correct Answer: B. Performance should be monitored across relevant populations with defined human oversight.

Hospital Information Systems
Chapter 10 of 15