The Information Technology department of many healthcare IT organizations may support a hundred or more applications: everything from the electronic badge system for clocking in, lab software, pharmacy software, all the way to critical monitoring software for patients in the ICU. At any given time, any number of these systems may be in the process of major or minor upgrades, bug fixes, feature changes, and configuration changes. That is why every organization needs an information technology change control structure. It is sometimes called IT change management or change board, but the concept is the same:
Change Control in IT is intended to provide a structured and efficient process to be sure changes to systems are done with the highest possible level of quality, safety, and accountability.
Even if you don’t work in a healthcare setting, stay with me, and I think you’ll see that change control concepts apply to just about all IT settings.
At the end of the day, responsibility for the success of these systems lies with the application analysts, their managers, and ultimately, the Chief Information Officer (CIO). There are countless things that can go wrong:
- Users may see different screens than what they expected;
- A seemingly innocent change of data formats can have unintended consequences. “You mean Canadians use numbers and letters in their Zip Codes?“;
- A clinical system may share data to other systems through an interface. We call this affecting downstream or upstream systems;
- The analyst responsible for an update on a certain date may be counting on help from a staff member who is already committed to another project on the same day.
The way that an IT department deals with these conflicts is to form a well organized Change Control Board. This is an authoritative governing group that approves and rejects most changes that occur in an organization.
Change Control Process
In order to successfully manage changes, there needs to be a clear definition of what a change request looks like. Let’s take an example of an organization that needs to implement a badge reader system on most Windows workstations so that users can log in with entering user IDs and passwords. Every change request should have these components:
- What is the actual need that is being addressed by the change? An example would be “All workstation users need to be able to scan their badges to log into the EHR system instead of typing user IDs and passwords“;
- What systems or processes are being introduced? In this case, we’re implementing a specific vendor solution to support badge reader authentication. We have hardware and software components;
- Does the change affect one user, a group of users, a department, or everyone? In this example, all clinical users in patient care areas will use the technology;
- What other teams within IT have you worked with, if this applies? In our example, we may have worked with the clinical engineering department to be sure they are aware of the badge reader hardware, and that the equipment has tracking tags;
- When will this change go into production? Consider holidays or any other critical dates of other projects;
- Describe how you tested this change. You’ll need to explain all the steps you used to validate the badge readers, what types of users you tested with, and in what environments;
- What is your roll-back plan? In other words, how will you correct the change if something unforeseen goes wrong?
Change Control Board
Here are some features of a typical change control board, including some common ground rules:
- Meets at regular intervals. During times when no major projects are going on, they may meet weekly. When there is a major project that involves many groups or departments, Change Board may meet daily;
- A representative from each IT team must be present at every meeting. It usually rotates among each team’s members, weekly or monthly;
- Not all changes necessarily need to be presented for approval. For example, changing out a PC in the billing office probably doesn’t require approval. However, upgrading the billing software to a new version certainly would require approval;
- If you don’t speak up about a proposed change, or if you don’t show up, that is implied approval. If something breaks that could have been avoided if you had been present, it’s on you!
- There is usually some tracking system that is visible to all members, and where proposed changes are logged and assigned a number. Most often, it is a web based form on an internal web portal. Sharepoint is a very common platform for this;
- Usually items are reviewed in the order which they were entered into the change log;
- There is usually a leader, but that single person rarely has veto power.
- Decisions are discussed and resolved by the group by consensus. If there is an impasse while the team attempts to decide on an item that needs to be tabled for further review, then the default decision is to deny the proposed change. You know the phrase, “better safe than stupid”.
The Change Board will also want to decide if changes moved from a release environment to a QA environment need to be approved, or if approval is only required for changes that go from QA to Production. If you don’t understand what I mean by referring to “environments”, check out this post on Healthcare IT System Architecture.
How Do You Present Your Requested Change?
Presenting a change request item to your change board can be intimidating at first, and that’s actually a good thing. The intention is to make you think about the implications of the change you are proposing.
It’s important for members to not take decisions personally. The main goal is reliable and safe delivery of technology and services to our customers.
Closing The Loop
Once your change has successfully gone into production, you will probably need to update your change item to document that the change was completed. There is usually nothing else that needs to happen at this point.
IT Change Management Safe List
Analysts and technicians usually have many routine changes that should not require any change board permission, even though they still need to be tracked. Examples are the addition of new users, PCs, or printers in a system. These items will be documented in the change control safe list, which should be available for everyone to see. As needs and projects change, items on the safe list may also need to be reviewed and updated.
Emergency Change Control
There is usually an emergency or off-cycle change control process in place in which serves to authorize emergency changes. It’s advisable to have signoff by 1) a technical peer reviewer different from the requester, and 2) one or two managers or directors.
Change Control Example Form
Here is an example change control form that contains the items that a Healthcare IT change board would want to track:
Next Up: What Is IT Help Desk Software? Learn about how help desk software is used to track and resolve IT issues.
There you have it. A solid change control process is one of the most important things you can do to maintain your IT department’s credibility and trust in your organization.
