The Information Technology department of many Healthcare IT organizations probably supports 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 change management, or change board, but the concept is the same:
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.
Change Control Procedures
Here are some common features of a typical change control process, 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.
Here are some of the items that you are expected to explain:
- What change are you making?
- Does the change affect one user, a group of users, a department, or everyone?
- What other teams within IT have you worked with, if this applies?
- When will this change go into production?
- Describe how you tested this change.
- What is your roll-back plan? In other words, how will you correct the change if something unforeseen goes wrong?
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.
Change Control 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. Thanks for taking a minute to read this post. You can always contact me from this site, from Google+, or find me on Twitter at @LearnHealthTech.
Latest posts by Dave Newman (see all)
- Healthcare IT Certifications 2018 - Jan 7, 2018
- Ultimate Guide To Launching A New Health IT Department - Dec 17, 2017
- From A Hospital Department To IT - Jun 14, 2017