In a previous blog, I discussed ITIL and what I perceive as a growing trend of love affairs with PROCESS instead of RESULTS. Since that blog, several readers, including two healthcare CEOs and a Chief Medical Officer, contacted me privately to express their frustrations with their CIOs’ ITIL obsession — particularly around change control — and the bog-down effect it has on business and clinical operations. Those CEOs and CMOs are frustrated because they initially endorsed what was pitched to them as IT best practices, but now are feeling the impact of what has become an IT monster.
Need and Purpose for Change Control
The objective of Change Control in this context is to ensure that changes to the organization’s IT assets are reviewed within the broader accountability of leadership for the effects they will have on business and clinical operations. Information Systems Change Control can ensure repeatable, predictable methods, processes and procedures are used for all changes; facilitate efficient and prompt handling of all changes; and maintain the proper balance between the benefits of system changes and the potentially detrimental impact of those changes. An important concept in Change Control is balancing the risk of an agile process and delegated change control authority with the lower risk and burdensome overhead of centralized change control authority. The Information Systems team is expected to display the utmost in professional judgment in balancing this risk; otherwise a burdensome and centralized change control process is the only alternative.
The need for changes in the configuration of IT assets may arise:
- Reactively in response to problems or externally imposed requirements, e.g. legislative changes
- Proactively from seeking improved efficiency and effectiveness, security, safety, and IT supportability
- To enable or reflect business initiatives
- From programs, projects or service improvement initiatives
- From product upgrades related to any of the above
Principles and Directives
1. There are four levels of Information Services Change Control Authority in the organization, as described below in the accompanying table. Each level is responsible for approving increasingly higher risk changes. When planning for system changes, in principle, we prefer more frequent, simple and lower risk system changes over less frequent, more complex, and higher risk system changes.
- The Level 1 Change Control Authorities are authorized to implement system changes without prior approval if the system change is low risk and the Level 2 Change Control Authority is notified of the change in a timely fashion, preferably either immediately before or after the change is made.
- The higher the risk associated with the change, the more important that the change must be escalated to the next Change Control Authority for review and approval. When in doubt, escalate the Change Control to the next level for review and approval.
2. All changes which could directly affect patient safety or are associated with the organization’s revenue cycle and financial management controls must be escalated at least one level and approved prior to implementation.
3. Assessing Risk
- Risk is defined as:
- Risk = (Probability of a mistake being made as a result of the system change) x (Consequences of the mistake)
- Probability is primarily determined by the complexity of the change and the experience of the staff with that exact type of change
- Consequences are primarily determined by the number of people or the finances (dollars) which could be affected if a mistake is made as a result of the change.
- Risk can be assessed by considering the consequences of an error resulting from the change, on the following areas:
- Patient safety
- Diagnostic services efficiency and/or accuracy
- Patient data privacy and confidentiality
- Employee data privacy and confidentiality
- Financial revenue and accounting accuracy
- Physician and nursing efficiency
- Administrative services efficiency
- Information systems performance and reliability
- Information systems security
- Legal compliance
- Professional accreditation
4. Separation of Duties
An important principle in Change Control is the separation of duties. Information Services staff members are expected to follow this principle, in particular as it relates to changes which affect our revenue cycle and financial management systems. Separation of duties is the concept of having more than one person required to complete a task. It is alternatively called segregation of duties. Separation of duty has as its primary objective the prevention of fraud and errors. This objective is achieved by disseminating the tasks and associated privileges for a specific business process among multiple users. For example, the separation of duties principle does not allow for a single person to design, develop, test, and implement a change to an information system. As a minimum, the same person cannot test a change and also move that change into the production environment. A separate person must be involved in the implementation of the change in the production system.
5. Change Control Records and Audit Trails
- Information Services staff members are expected to maintain a record of system changes, including as a minimum:
- Purpose of the change
- Date and time of the change was moved into production
- Who tested the change
- Who moved the change into production
- Who was involved in the review and approval process for the change
6. Change Control Escalation Matrix
The linked document above is an excerpt, anonymized and generic, from our change control policy in the Cayman Islands national health system. It represents what I believe is a balanced approach to change control that everyone—CIO, CEO, CMO—can feel comfortable with. With this method, we can avoid seeing mobs chase the change control monster. Good luck!
Share Your Thoughts
You must be logged in to post a comment.