INFORMATION TECHNOLOGY @ JOHNS HOPKINS

SECTION:604.1

PROCEDURE:Change Management

REVISION DATE:April 2007

PURPOSE:To ensure orderly control of all information system changes by authorized personnel; to ensure communications to all affected areas; to provide the means of tracking all changes.

PROCEDURE

  1. All changes that affect service to customers of information technology controlled by Information Technology @ Johns Hopkins (IT) must be recorded in the Change Management component of the ServiceCenter System. A Change Request and all associated information are required for all changes.
  1. Changes, additions, or deletions in the following areas are covered by this procedure:
  • Computer Hardware - Any hardware on the computing platforms supported by IT, or that affect JHM/JHU.
  • Network Equipment - Any IT supported hardware used to connect IT controlled and managed devices.
  • Computer Software - Any system or support software on platforms supported by IT.
  • Facilities - Any physical or environmental aspect of IT controlled computer facilities.
  • Application Software - Any IT supported software used to provide the business functions of JHM/JHU.
  • Data - Computer files containing data needed to process and support business, clinical and student functions.

  1. The following are key responsibilities in the change management process:
  1. All change requests must be assigned the proper category, priority assignments, and risk level (see Sections 604.2, 604.3, and 604.4). These are to be reviewed by all affected managers to ensure changes are properly assigned.
  1. The manager of the area that submits a change is responsible for ensuring that all changes have had proper customer authorization, sufficient lead time, fully coordinated scheduling, completed and approved testing, updated documentation, all change control forms are completed as required and for ensuring that all appropriate documentation is maintained for audit purposes.
  1. The proper lead times must be observed to successfully implement the change. (see Section 604.5)
  1. All change requests must have the proper levels of approval. (See Section 604.6)
  1. There are certain required activities that must be followed for each change to be approved for implementation. Completion of these activities is reflected in the change request through the use of various phases. (see Section 604.7)
  1. Change Control Management is responsible for keeping all change requests under centralized control. Change Control Management (CCM)is responsible for reviewing all change control requests to ensure that all information needed for ServiceCenter is provided and the requests are properly entered into the system.
  • All changes are submitted to Change Control Management(see Section 604.9) via the ServiceCenter System. CCM will approve all schedules, determining when changes can be made, approves all schedules, reviews impact to customers and other systems and will authorize closing when a change is completed.
  1. Various reports on change activities will be prepared for review and communications purposes (see Section 604.10). Change Control Management is responsible for ensuring these reports are produced and distributed.
  1. Documented procedures for the entry and update of changes into the ServiceCenter System are created and maintained. This responsibility lies with Change Control Management. (see Section 604.8)

SECTION:604.2

PROCEDURE:Categories

REVISION DATE:November 2006

PURPOSE:To ensure that the changes made to information systems and services are properly categorized for appropriate approvals and communications.

PROCEDURE

Change Categories

There are numerous categories used to differentiate between types of changes. These categories allow the proper approvers to be assigned to a change request and assist in determining the level of communications for the change. The change requestor is responsible for identifying the proper category for a requested change. The normal change categories are presented below:

Category

/

Description

System HW / Mainframe or mid-range hardware. This might include Disk Storage devices, DEC hardware, IBM Mainframe, tape drives.
System SW / Mainframe or mid-range operating software. This could include OS/390, CA7, TSO, TPX, BDT.
MSC Offsite Network / The MSC offsite network environment.
Network HW/SW / Network equipment and it’s related software. This includes routers, switches, gateways, network circuits or any piece of equipment that supports connectivity to IT.
Telecom / Voice and data telecommunications lines and equipment. This could include phone lines, switches, and the software used to support these functions.
Network Info Security / Network security including firewall changes.
Desktop/LAN / IT servers, LANs, or desktops (including Public Workstations). Also includes the software for these items such as GroupWise or Internet Explorer.
Facilities / The facilities and environment of the 1830 DataCenter.
Enterprise Services / Enterprise-wide support systems such as HIP, JHED, Fester, RAUL, WEB, and DNS.
Admin Systems / Application software to support the Hospital Admissions process. Included are applications such as EPIC, HDM, MEDD, PID, ZORS, HSCRC, VIP, MSO/CVO, Casemix, Charge Capture, Rehab.
Clinical Appls - ECLIPSYS / Specific Application software to support the Clinical process. ECLIPSYS (EMTEK/APACHE) is the only application for this category.
Clinical Systems / Application software used to support the Hospital Clinical process. This category includes EPR, WebEPR, Interfaces, Radiology, Lab Results and Reporting, Text Engine.
Finance/Admin Applications / Application software used to support the Hospital Financial and Administrative processes. This category includes AP, GL, Fixed Assets, HRMS, Material Management, KEANE, SMS/ADT, Keymaster.
Patient Care Systems / Application software used to support the Hospital Patient Care process. It would include Ordernet, Vision, BDM.
Database / Includes change made to business transactions contained in files or databases at both the Hospital and University.
UNV Financial Systems / Application software used to support University financial and administrative functions It includes AP, BASIS, Purchasing, and GA.
UNV Student Services / Application software used to support all Student functions. Included are SAM, SARS, USIS, ISIS, and the web related applications.
UNV HR/Payroll/Tax / Applications supporting University human resources, payroll, and tax.
H1 – HopkinsOne / Applications supporting all Enterprise
systems

SECTION:604.3

PROCEDURE:Type

REVISION DATE:November 2006

PURPOSE:To ensure that changes are typed according to the method in which they must be processed.

PROCEDURE

Change Type

The majority of changes are processed according to established lead times and are classified as a normal type. Some changes must be implemented to address open high priority problems and the normal Change Management process cannot be met. These changes are classified as an Emergency. All categories of changes may be classified as an Emergency when time is an issue to avoid loss of service to customers. Emergency changes do require a higher level of approval (see Approval Levels section).

In order to use Emergency one of the following must be true.

  1. The change is needed to restore immediate service.
  1. The change is needed to immediately fix an existing problem or meet regulatory compliance.
  1. The change is needed to avoid an outage in the immediate future.


SECTION:604.4

PROCEDURE NAME:Priority

REVISION DATE: November 2006

PURPOSE:To provide a level of importance for a given change to allow preference ranking with a group of similar changes.

PROCEDURE:

Change Priorities

There are 3 priority levels for changes. These represent the level of importance of installing a particular change. They allow ranking of importance when there may be conflicts with other change requests. The change requestor identifies the priority of a given change and provides a justification for this ranking.

The three priorities are outlined below. In order for a change to be placed in a priority it must meet one or both items in that priority’s criteria.

Priority

/

Criteria

1 /
  • Necessary to Meet Regulatory or Patient Requirements
  • Addresses a Critical Problem and Service is Disrupted

2 /
  • Necessary to Meet JHM/JHU Internal Requirements
  • Addresses a Critical Problem but a Bypass is Available

3 /
  • Meets a IT Requirement
  • Addresses a Non-Critical Problem


SECTION:604.5

PROCEDURE:Risk Levels

REVISION DATE:November 2006

PURPOSE:To ensure that the changes made to information systems and services represent an acceptable balance of risk, resource effectiveness, and potential disruption to customers.

PROCEDURE

1.Change Risk Levels

There are four risk levels for changes. Changes that could cause serious disruption to service should problems occur during implementation require a greater degree of evaluation and control than changes with less impact. The change requestor identifies the risk level. The appropriate area managers, Change Control Manager, or Change Control Committee may override risk selection.

All of the following factors are relevant to a change’s risk level:

a.Potential risk of change installation.

b.Complexity of the change.

c.Difficulty and length of time to install the change.

d.Ease of recovery, if the change must be backed out.

e.Potential impact of change failure.

f.Overall effect on customers.

2.Determining the Change Risk Level

All change requests must have the appropriate change risk category assigned, according to the guidelines presented in this procedure. The following table provides information that will assist in determining the appropriate risk level for a change. Also provided are a few examples of changes with their associated change risk level.

In general, if most aspects of a specific risk level apply, that risk level is most likely the correct one. Depending on unique conditions, some types of changes are candidates for one of several change risk levels. When this occurs, the higher risk level (lower number) should be selected.

CHANGE ASPECT / RISK LEVEL 1 / RISK LEVEL 2 / RISK LEVEL 3 / RISK LEVEL 4
RISK / uncertain of success / slight chance of failure / high probability of success / reliable (known to work)
COMPLEXITY / all (or most) systems and applications / multiple systems and applications / multiple systems but single application / single system or application
INSTALL PROCESS / complex; may be first time done / difficult; seldom done / simple; done frequently / easy; commonly done
BACK-OUT EFFORT / difficult or impossible; more time than install / involved; time consuming / moderate; less time than install / simple, quick
IMPACT OF FAILURE / major; difficult error detection / major; easy error detection / minor; easy error detection / insignificant or none; easily detected errors
CUSTOMER AFFECT / all or most customers; training or procedure changes required / significant number of customers; may require training or procedure changes / limited number of customers; training normally not required; Chapter 5 documentation affected (UNV) / one or no customers; transparent
CATEGORY / EXAMPLES
SYSTEM HARDWARE / new install, major upgrades / microcode updates / engineering
SYSTEM SOFTWARE / new releases, conversions / sysgen, i/o gen, new program products / minor enhancements, new tools / table updates, minor tuning
NETWORK / new equipment / node name/path / spool device
DESKTOP/LAN / server upgrades
FACILITIES / major electrical/cooling / moves, recabling
APPLICATIONS / new releases, conversions / specific fixes / functional enhancement / JCL, file reorganization
DATABASE / file organization / normal file reorg


SECTION:604.6

PROCEDURE NAME:Lead Times

REVISION DATE: November 2006

PURPOSE:To ensure that changes with different levels of impact are scheduled correctly and sufficient time is provided for change review and communications.

PROCEDURE:

  1. Lead time, in business days, is the amount of time required to adequately evaluate and plan for the change. It also represents the minimum time frame to notify all affected parties prior to the scheduled date of the change.
  1. Lead times are assigned based upon the risk level of a change. The higher the risk the more lead time required. Emergency changes are granted an exception to the lead time requirements.
  1. The time frames noted in the table start when the change request is entered into the Change Management Component of ServiceCenter. All changes with Risk levels of 1, 2 and 3 must be entered allowing sufficient time for review by the Change Control Committee which meets each Wednesday. In all situations it is always better to enter the change request into ServiceCenter as soon as possible.
  1. Emergency change requests are implemented when required. Complete justification information must be given describing why the change is an Emergency.

**Please Note – Changes that are submitted with less than 3 full

business days lead time will be processed as an Emergency.

Change Risk Level / Lead Time
1 / 11 full business days
2 / 9 full business days
3 / 6 full business days
4 / 3 full business days
Emergency / Same day

SECTION:604.7

PROCEDURE NAME:Approval Levels

REVISION DATE: November 2006

PURPOSE:To ensure that changes have the necessary level of approval based upon the assigned risk.

PROCEDURE:

  1. Approvals are required prior to change implementation. Emergency approvals may, at times, be obtained after the change has been implemented. However, every attempt should be made to obtain some management approval prior to implementation.
  1. Approvals must be provided by the indicated management (or their designated alternate). If the indicated manager is not available, then approval may come from a Director.
  1. Any modification made to a change request after initial approval of the Production Preparation phase, but before closure, will remove the approvals. It is the responsibility of the person making those modifications to be aware of this and re-obtain approvals prior to change implementation. This protects the approver from not knowing what changes may be made to the original change.
  1. Emergency change requests may need to be implemented prior to obtaining all necessary approvals. When this is the case, missing approvals must be obtained the next business day. Emergency changes require a higher level of approval due to the need to limit the practice of unplanned changes. Requiring the approval of a Director should decrease emergency changes and allow them to go through the normal process.

Change Risk Level / Approval Required
1 / Requesting Area Manager & Change Control Management
2 / Requesting Area Manager & Change Control Management
3 / Requesting Area Manager & Change Control Management
4 / Requesting Area Manager & Change Control Management
Emergency / Requesting Area Manager, Requesting Area Director, and Change Control Management

SECTION:604.8

PROCEDURE NAME:Required Activities

REVISION DATE: November 2006

PURPOSE:To ensure that necessary activities and documentation accompany changes and that changes progress through the appropriate phases.

PROCEDURE:

  1. Specific activities must be completed for any change request to be approved for implementation. These activities ensure that proper planning and communications have taken place for a smooth change implementation. The following activities and documentation are required for all change requests.
  1. Change Request (within ServiceCenter) must be completed. For changes to application programs or modules, the member names must also be provided in the Change Request.
  2. Management approvals indicating an approved project implementation plan, testing of the change was successful and customer sign-off. Appropriate documentation will be maintained for audit purposes.
  3. Procedural documentation must be supplied to include:
  • Run instructions
  • Escalation procedures for software and hardware problems (includes IT and customer notifications)
  • Distribution instructions
  • Backup and file retention instructions
  1. Disaster Recovery documentation updates.
  2. Back out procedures.
  3. Change Control Management approval obtained.
  4. Completion of any necessary training.
  1. As the risk level of a proposed change increases the level of detail for each of the above items should increase also. For example, higher risk changes require that implementation planning and approval are done through a formal implementation review (such as documented in the ISLC). They may also require that structured documentation and formal test results be completed. It is the responsibility of the requestor’s management to ensure that the proper activities are completed, although the Change Control Committee may deem that certain items are necessary for their review.
  1. Emergency changes require that the same activities be completed as normal changes. Due to the nature of emergency changes some of these activities may need to be completed after the change has been implemented. At a minimum, the Operations Manager must be made aware of, and approve, the change. Contact information, in case of problems, must be made available. As quickly as possible after the change is implemented any activities not completed prior to the change must be completed.
  1. It is the requestor's responsibility to monitor the implementation and initial processing cycle to ensure that the change has been successfully completed. However, only Production Support and Data Control can update production libraries. Application programmers cannot move their own programs into production.
  1. At the completion of the change, the assignee must update the change request to reflect the status of the implementation. Closing comments must be entered into the associated text area. After this information is entered, Change Control Management authorizes changes for closing.
  1. As changes progress through their various activities, the change request is updated to reflect completion of change phases. There are 3 phases associated with normal change requests.
  1. Production Preparation Phase
  • Change is entered into the Change Management Component in ServiceCenter. Detail descriptive information is provided.
  • Testing and sign-off has been obtained as well as completion of required project plans or other documentation.
  • Pending requestor manager review and approval.
  1. Approval Phase
  • Requestor management has approved the change request and moved it into this phase.
  • Pending Change Control Committee review and Change Control Management approval. The requestor must attend the Change Control Committee meeting and be prepared to discuss the change.
  1. Production Phase
  • Change Control Management has approved the change request.
  • After implementation of the change the requestor must update the request indicating the level of success for the change. When appropriate, requestor should verify customer acceptance of change and indicate such in the change request.
  • Change Control Management closes change request.