Issues Management

1
EHR RoadmapWebEx
Stratis Health, the Minnesota Quality
Improvement Organization in partnership with
other QIOs, presents . .

• Issues Management
• and
• Change Control

2
Presenter

• Margret Amatayakul
• RHIA, CHPS, CPHIT, CPEHR, FHIMSS
• President, Margret\A Consulting, LLC,
  Schaumburg, IL
• Consultant to Stratis Health DOQ-IT Project
• Independent information management and
  systems consultant,
  focusing on EHRs and
  their value proposition
• Adjunct faculty College of St. Scholastica,
  Duluth, MN, masters program in health informatics
• Founder and former executive director of
  Computer-based Patient Record Institute,
  associate executive director AHIMA, associate
  professor Univ. of Ill., information services
  IEEI
• Active participant in standards development,
  HIMSS BOD, and co-founder of and faculty for
  Health IT Certification

3
EHR Roadmap
Implement
4
Objectives

• Plan to address issues management early in
  implementation or even earlier
• Establish a formal issues management program
• Coordinate issues management with change control
• Utilize change control to manage ongoing system
  maintenance, upgrades, and new components

5
Issues Managementand Change Control

• Issues Management

6
Issues Management

• Identifying issues
• Determining responsibility for their resolution
• Setting in motion the steps to resolve the issue
• Tracking the steps in resolving the issue to
  ensure they are accomplished or to escalate
• Verifying the resolution of the issue
• Documenting the issue and its resolution

7
Issues Identification

• Most obvious an element of testing fails and
  requires fixing
• Also a project is going over time and/or budget
• Issues, however, can be
• Identification of potential risk areas
• Disagreements
• Among persons in the clinic
• Between clinic and vendor
• Issues can begin as early as EHR readiness
  assessment and planning

8
Project Creeps

• Scope creep any change in project not in
  original plan
• Generally cannot be prevented
• Needs to be managed
• Effort creep work is being performed, but it is
  not productive
• Poor results may be a skills problem
• Hope creep reporting more progress than actual
• Often insidious and can have a disastrous effect
• Feature creep little, well-intentioned changes
  adding up to much more
• Similar to scope creep, but more insidious

9
Responsibility

• Any one can and should (fee comfortable about)
  raising issues
• It is better to resolve an issue early
• Than to let it fester to the point where it
  becomes more difficulty/costly to fix or even
  derails a project
• Project manager
• Should have antennae out at all time to identify
  issues early
• Should have in place the mechanism to
  continuously monitor for issues
• Assigning responsibility
• Project manager holds considerable but not sole
  responsibility for identifying issues
• Project manager is not responsible for resolving
  the issues
• Project manager is responsible for identify who
  should solve the issue and monitor that it gets
  solved
• Project manager is responsible for identifying
  when issue resolution needs escalation

10
Project Manager Characteristics

• Attention to detail
• Well developed instincts
• Responsive to instincts
• Comfortable in delivering bad news
• Accepting of issues in a blameless state
• Has authority to escalate, also without blame

11
Planning Steps for Resolution

• Mini project plan within the broader scope
• Appreciate the effect on project progress
• Dependencies
• Critical path
• Gain agreement
• That the plan is realistic
• Cost/time/staffing
• Outcomes
• Does the same person attempt to resolve or
  someone else?
• Add the resolution plan to the overall project
  plan

12
Resolution Tracking

• Track resolution plan at least as closely as
  all other components of plan
• Monitor for patterns of issues
• Is it always the same person?
• Is it always the same type of task
• System build
• Interface writing
• Testing
• Training
• A pattern of issues is also call for escalation

13
Escalation

• Knowing when and to whom to escalate an issue is
  a critical part of a project managers
  responsibilities
• When an issue is not resolved within the new
  budget, timeframe, or parameters it needs to be
  escalated
• Project governance structure should exist to
  recognize chain of command
• Clinic side
• Vendor side
• Escalation should never be one-sided

14
Verification of Resolution

• Issue management is also important relative to
  vendor contract.
• The vendor will also maintain an issues log, and
  may require the organization to sign off as
  issues are resolved.
• However, issue resolution can be in the eye of
  the beholder, so it is important for the
  organization itself to also track issues and
  ensure that the vendors log is signed off only
  when the organizations own issues log reveals
  satisfactory resolution.

15
Issues Managementand Change Control

• Formal
• Issues Management
• Program

16
Formal Program

• Documentation
• Issues log
• Journal
• Files
• Governance
• Escalation
• Decision-making in general

17
Issues Log

• Organizational responsibility to track and sign
  off on resolution
• Vendor will also maintain an issues log
• Software exists to help manage issue management,
  and link to Critical Path Method (CPM) project
  planning, provides a dashboard, etc.

18
Journal and Files

• Bound book that records actions
• Date/time stamp of communications in electronic
  form
• Maintenance of all emails, record of all calls
• Electronic journal permits management of the
  information
• Scan paper documents if necessary to track within
  files
• Establish a file naming structure!

19
EHR Decision Governance
EHR ORGANIZATION
DECISION MAKING -Financing -Contract
Approval -Physician Compensation -Contract
Negotiation -Project Staffing -Contract
Management -Communication Plan -Functional
Requirements -Selection of Vendor of
Choice -Benefits Expectations -Migration
Path -Turnover Strategy (Clinic Phase-in) -Chart
Conversion Strategy -Design of Summary
Lists -Adoption of Practice Guidelines -Clinical
Work Flows -Clinical Documentation
Standards -Customization of Screens and
Templates -Chart Conversion Specifics -Data
Dictionary/Master Files Tables -Clinical
Process Redesign
Practice Governance
Practice Admin
EHR Steering Ctte
EHR Project Mgr
Med Dir Info Sys
IT Support Staff
Clinical Leads
PMS/Bus Off Team
Clinical Support Team
Physician Team
Bus Off Mgr
Domain Teams
Domain Teams
Domain Teams
Domain Teams
Domain Teams
Domain Teams
20
Issues Management and Change Control

• Change Control

21
Change Control

• Very often a change to software will be needed to
  resolve an issue.
• Change to the source code (usually performed by
  the vendor)
• Change in templates that is able to be performed
  by the organization
• Changes should be tracked
• Changes almost always have an impact on another
  part of the software
• For an EHR, changes can have a huge ripple effect
  throughout the system, impacting clinical
  decision support and the care of the patient
• A formal change control process is necessary
• Change control should be annotated on the issues
  log and further detailed in a change control form
  that is maintained either by the project manager,
  or more commonly by the I.S. department.

22
Purpose

• A formal change control process is used to
  eliminate and/or reduce disruptions and maintain
  acceptable levels of service for normal
  operations during the implementation of changes
  in information systems by monitoring and
  managing
• Frequency of changes
• Length of time required to implement changes
• Impact of changes on business units
• Changes resulting in problems
• Concurrent changes

23
Policy

• All of the following changes will require not
  only management approval, but full documentation
• 1. New computers installed
• 2. New applications installed
• 3. Different configurations implemented
• 4. Patches and updates installed
• 5. New technologies integrated
• 6. Updated policies, procedures, and standards
• 7. New regulations and requirements
• 8. Identified and implemented fixes for network
  or system problems
• 9. Different network configuration
• 10. New networking devices integrated into the
  network

24
Outcomes

• A formal change control process provides
• Central inventory of all information systems and
  their current upgrade status.
• Central coordination and control of all change
  management functions.
• Assurance that change controls meet vendors
  contractual obligations.
• Testing and validation that security features and
  controls have not been altered or compromised as
  a result of a hardware or software change.

25
Documentation

• A formal change control process provides a
  central repository for all change data that will
  be used to measure and report on the
  effectiveness of the change management system by
  evaluating
• Impact of business unit objectives
• Percent of successful changes
• Change window overruns
• Number of unrecorded changes and percent that
  failed.
• Number of required backouts and percent that
  failed
• Number of unplanned/unscheduled outages due to
  change

26
Elements of Program

• Change Request
• Technical and Business Assessment of Change
• Management Approval of Change
• Documentation
• Testing
• Implementation
• Reporting

27
Change Request
28
Assessment of Change
29
Testing and Implementing

• All changes must be tested in the test
  environment prior to moving them to the
  production environment
• Monitoring of the change test is the process of
  tracking and documenting the final test of the
  change prior to actual change implementation and
  communicating the results of the test to all
  concerned parties
• All changes must reflect the same or greater
  level of security enablement as the original
  system. Testing must include a test of the
  security features
• All changes will be implemented with the same
  diligence as the original system
• Changes must be monitored and tracked
• The duty to report the results of change
  implementation are equivalent to the duty to
  report new system implementation
• The evaluating the overall operations and
  achievements of both the change and the entire
  Change Management System
• These achievements are determined through reports
  created from change records and statistics

30
Issues Management andChange Control

• Preparing for Ongoing System
• Maintenance and Upgrades

31
Retention

• Documentation of changes will be retained for the
  life of the applicable hardware or software
• Documentation of changes that are delayed or
  disapproved must also be retained for the life of
  the hardware or software

32
Impact of Change

• Change to data dictionary impacts
• Data collection
• Decision support
• Reporting
• Change to application results in
• Change to other applications
• Change to interfaces
• Change in workflow determines
• New data capture requirements
• New rules for decision support

33
Stratis Health is a non-profit independent
quality improvement organization that
collaborates with providers and consumers to
improve health care.
This presentation was created by Stratis Health
under a contract with the Centers for Medicare
Medicaid Services (CMS). The contents do not
necessarily reflect CMS policy.