System Design Life Cycle: A Framework


System Design Life Cycle: A Framework

Susan K. Newbold


In the past, clinical systems implementation projects were considered successful when implemented on time and within budget. Later, the concepts of end-user perceptions determining project success in conjunction with streamlining clinician workflow–layered clinical systems projects with additional success criteria. In the recent past, the focus for clinical systems implementations has been on systems improving patient safety through evidence-based practice (EBP) while meeting the federal requirements set forth in the Health Information and Technology for Economic and Clinical Health (HITECH) Act of 2009 (, n.d.).

As part of the HITECH Act, the Centers for Medicare & Medicaid Services (CMS) set forth a program providing organizations that demonstrate the meaningful use of an EHR to improve patient safety significant financial incentives. Today, the successful system implementation project must be completed on time and within budget, and offers end users streamlined workflow, with added safety in the delivery of healthcare and qualifying the organization for the financial benefits of meeting the meaningful use requirements.

The System Design Life Cycle (SDLC), also known as the System Life Cycle (SLC) outlined in this chapter, discusses the tasks multiple disciplines must accomplish to produce a technically sound, regulatory compliant and user-friendly EHR supporting safe, effective, and efficient patient care delivery. The SDLC framework described by the American Nurses Credentialing Center’s Nursing Informatics Test Content Outline (2018) consists of four major phases: (1) planning and analysis; (2) designing and building, (3) implementation and testing, and (4) monitoring, maintaining, supporting, and evaluating. The chapter further defines these phases into the key tasks of a practical clinical systems implementation checklist and high-level work plan used successfully for real-world implementations in the acute care setting. Many examples in this chapter refer to the implementation of an EHR; however, the framework, phases, and tasks discussed can and should be applied to any clinical system or application implementation.

There are two text books which are often utilized for the systems analysis and design process for healthcare projects. Dennis, Wixon, and Roth (2015) also use four phases: (1) planning, (2) analysis, (3) design, and (4) implementation. Kendall and Kendall (2014) break the systems development life cycle into seven phases: (1) identifying problems, opportunities, and objectives, (2) determining human information requirements, (3) analyzing system needs, (4) designing the recommended system, (5) developing and documenting software, (6) testing and maintaining the system, and (7) implementing and evaluating the system. Analysts may disagree on the exact number of phases, but they generally agree that an organized approach is needed.


The EHR is a longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting. Included in this information are patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data, and radiology reports. The EHR automates and streamlines the clinician’s workflow. The EHR has the ability to generate a complete record of a clinical patient encounter as well as to support other care-related activities directly or indirectly via interface. See other chapters in this book including the chapter on computerized provider order entry.

The skills required to deliver direct patient care include the ability to understand and coordinate the work of multiple disciplines and departments. As multiple departments work in concert for optimum and safe patient care delivery, the components of an EHR integrate data in a coordinated fashion to provide an organization’s administration and clinicians demographic, financial, and clinical information. The SDLC provides a framework to attain a successful implementation.


The Centers for Medicare & Medicaid Services (CMS) is the single largest payer for healthcare in the United States. Nearly 90 million Americans receive healthcare benefits through Medicare, Medicaid, and the State Children’s Health Insurance Program (CMS, n.d.). As the costs of healthcare increase, both the US population as well as the US government have become more critical of a payerbased health system. Four factors impacting healthcare payments and hospital information systems implementations are the evolution of evidence-based practice, the Federal Meaningful Use requirements set forth in the HITECH Act of 2009 now evolving to Promoting Interoperability, the cost of technology, and the use of project management principles.

Evidence-Based Practice

Melnyk and Fineout-Overholt (2015) define evidencebased practice (EBP) as a problem-solving approach that incorporates the best available scientific evidence, clinicians’ expertise, and patients’ preferences and values. The purpose of EBP is to utilize scientific studies to determine the best course of treatment for a patient. Functionality within the EHR can provide access to the studies to understand the recommended treatment while reviewing a patient’s data in real time.

Federal Initiative—HITECH Act 2009

This act seeks to promote the meaningful use of information technology to improve patient safety in healthcare delivery. The initiative requires an organization or provider to demonstrate consistent and appropriate use of information technology. Adoption of the technology is required in stages, with increasing numbers of requirements in each stage. Federal financial incentives are awarded to those meeting each stage. Financial penalties will be levied against organization failing to meet the requirements (, n.d.).

The Meaningful Use requirements leverage the results published in studies indicating a marked increase in patient safety when specified functions of an information system are utilized. In addition, standardized terminology criteria permitting comparison of healthcare treatments and outcomes across healthcare facilities are incorporated into the later HITECH Act’s stages. CMS has evolved Meaningful Use into Promoting Interoperability in an attempt to encourage a greater level of interoperability among systems ( Legislative and legal aspects of informatics are discussed in another chapter.

Technology: Cost, Benefit, and Risk

Technology costs are high, increasing the risk of significant financial losses from a poor implementation. Vendors deliver the same software to clients; the success of an information system project often rests on a well-planned and well-executed implementation. A well-planned implementation dovetails an organization’s strategic goals and culture, with the introduction of and ability to assimilate technology and workflow changes into the daily practice of healthcare delivery. The SDLC provides a structured implementation approach to accomplish this.

Healthcare information systems implementation time lines are often long, spanning 10 to 16 months for a full hospital information system implementation. Most organizations have implemented at least one EHR and are either upgrading their current system or switching to a new system. The SDLC approach is still utilized.

Increasing a project’s risk level, a technology generation, now only months in length as opposed to years, can render partial obsolescence of a system by one technology generation before the first productive use of a system is sometimes obtained. A well-planned and executed implementation, on the other hand, provides a high level of risk mitigation and cost containment. It is important to remember that technology is not the best solution to every problem; failure to recognize problems caused by inefficient processes from an information system problem contributes to the risk and potential costs of a system.

Project Management

With roots in the construction industry, a significant body of knowledge in the area of planning and tracking large-scale projects has evolved. The Project Management Institute (PMI) has become the central and certifying organization for project management professionals. The Project Management Plan (PMP) developed through PMI’s efforts has migrated to the Information Technology (IT) area and is commonly called a project work plan (Project Management Institute, 2019). It is the main planning document for an IT project and describes how major aspects of the project will be executed and managed. The work plan is a living document, updated continually throughout the project. Nurses have the ability to coordinate and manage multiple diverse care situations; this affords them strong skills to manage complex projects using a Project Workplan as a primary tool. An excellent text with healthcare examples is Information Technology Project Management, by K. Schwalbe (Schwalbe, 2016) (see Chapter 15, “Healthcare Project Management”).

A second essential tool for clinical implementations is the project’s “issues list.” As concerns, unusual situations, special education/training needs, programming errors, sequencing concerns impacting workflow, and new regulations are uncovered, they are placed on the issues list. Issues are added to the list and prioritized in relation to other issues and to the project goals and assigned an urgency status. Examples of issue statuses are open, in progress, testing, and closed. The progress of an issue is tracked by the team on a regular basis with short progress notes added to the issue. When a resolution is reached, the resolution is documented in the issues list and the status is updated.

The resolution documentation detail helps eliminate the need for the team to revisit the decision. Suggested data elements in an issue’s list are as follows:

•   Issue number

•   Status

•   Date added to the list

•   Person identifying the problem/adding it to the list

•   Module/application involved

•   Description of the problem/issue

•   Type of problem (e.g., programmatic, training, process, hardware, network)

•   Note date

•   Notes (e.g., work/efforts to resolve issue)

•   Responsible party

•   Resolution date

•   Resolution description


The System Life Development Life Cycle is defined by the major components of (a) Planning, (b) Analysis, (c) Design/Develop/Customize, and (d) Implement/Evaluate/Maintain/Support. While this chapter discusses phases of the SDLC related to an EHR implementation in an acute care setting, it is applicable to many healthcare settings and projects. To continue to meet new regulatory and professional standards, EHRs and software applications must be continuously updated and upgraded in the Maintenance Phase.

Regardless of the size or type of the system, any EHR, single application implementation, or upgrade project should address each of the items on the clinical system implementation checklist presented in Fig. 12.1. Though not every project will require interfacing or data conversion or the addition of new devices, review of the checklist’s steps will assure that essential considerations are not overlooked (Fig. 12.1).


• FIGURE 12.1. SDLC Stages in Relation to Clinical Software Implementation Checklist.

The SDLC phases use a problem-solving, scientific approach. Problem-solving begins with observation and understanding of the operations of the current systems or processes, sometimes referred to as the “current state.” The second phase requires an in-depth assessment and definition of the new system’s requirements: defining the “future state.” Designing, developing, and customizing a plan to meet requirements are addressed in the third phase. The fourth phase, implementing, evaluating, supporting, and ongoing maintenance, assures the system is sustainable after implementation.

Nurses’ daily use of the Nursing Process, a problemsolving methodology, underlies the successes nurses have achieved in clinical informatics. Countless iterations of the problem-solving methodology are used during the implementation and updating/upgrading of software.

Inherent in the implementation process is the need to recognize and manage change and its impact on patient care delivery and clinician work patterns/workflow. Often, finding a balance between the technical data capture criteria and the daily workflow of clinicians is required. Details are discussed in Chapter 14, “System Life Cycle Tools.”

As noted, vendors supply essentially the same software to clients at the time of purchase. The abilities of the project team members and organization to introduce and assimilate changes into daily practice can determine the success of a project. Literature focusing on the workflow impact of an EHR and the cultural impact on an organization are well documented by the Project Management Institute (PMI) and the Healthcare Information Management Systems Society (HIMSS). Lorenzi, Novak, Weiss, Gadd, and Unerti (2008) all stress the need to manage the change process foundational to an EHR implementation if success is to be attained.

Attempting to implement or upgrade a system without reviewing each of the checklist items within the SDLC framework generally results in failure in one or more of the following areas:

•   EHR or application does not meet the stated goal of the project.

•   Failure to gain end-user acceptance.

•   Expenditures exceed budget.

•   Anticipated benefits are unrealized.

In recent years the quality and abundance of online resources specific to clinical systems implementation have grown significantly. Due in large part to the Federal HITECH meaningful-use requirements, the PMI and HIMSS both offer training and certification processes specific to healthcare-related projects.

The following online sites provide additional and supporting information:

American Health Information Management Association (AHIMA):

American Medical Informatics Association (AMIA):

Healthcare Information and Management Systems Society (HIMSS):

Project Management Institute: Promoting Interoperability (PI) Programs:

The Office of the National Coordinator for Health Information Technology (ONC):


The planning phase of the project begins once an organization has determined an existing requirement may be filled or solved by the development or implementation of an EHR or application. Establishing the committee framework to research and making recommendations for the project is an important first step.

The key documents created in the planning phase are the following:

•   Project Governance Structure

•   Gap Analysis

•   Feasibility Study

•   Project Scope Document

•   Development of a high-level work plan and resource requirements

Governance Structure and Project Staff

The clinical leadership of an organization is highly involved in the establishment of an EHR committee structure. The organization’s strategic goals and priorities must be reviewed and considered. The informatics nurse specialist and information systems management team provide oversight; however, committees work to develop the structure and participate to best guarantee the success of the project. Assigning the appropriate resources, whether financial or personnel, is a critical success factor.

Evaluations of both successful and less than successful implementations have stressed the need to anticipate the impact of the new system on the culture of the organization and to take active steps to mitigate the effects of change on the organization (Lorenzi et al., 2008). Transition management is a series of “… deliberate, planned interventions undertaken to assure successful adaptation/assimilation of a desired outcome into an organization” (Douglas & Wright, 2003). The informatics nurse often leads the assessment and documentation of the “current state” and development of the desired “future state.” Cognizance of the new system’s impact serves as a visible leader in the transition management efforts.

Steering Committee

Before an EHR is developed or selected, the organization must appoint an EHR steering committee. The EHR steering committee, composed of internal and external stakeholders, is charged with providing oversight guidance to the selection and integration of the organization’s strategic goals relative to the EHR requirements. During the planning phase, the projected return on investment (ROI) is established. The Steering Committee members’ collective knowledge of the organization’s daily operations provides global insight and administrative authority to resolve issues. In most facilities, the Steering Committee has the ultimate authority for decision-making (Fig. 12.2).


• FIGURE 12.2. Clinical Information System Steering Committee Structure.

Project Team

The project team is led by an appointed project manager (often the Informatics Nurse Specialist) and includes a designated team leader for each of the major departments affected by the system selection, implementation, or upgrade proposed. The objectives of the project team are to (1) understand the technology and technology restrictions of the proposed system, (2) understand the impact of intradepartmental EHR decisions, (3) make EHR decisions at the interdepartmental level, and (4) become the key resource for their application. A stated goal for the selection, implementation, or upgrading of an EHR is to improve patient safety and care; gains made by one department at the expense of another department rarely work to improve overall patient safety and care delivery. The project team’s ability to evaluate multiple departments’ information requirements in light of the capabilities of the proposed system is integral to overall success. Issues unable to be resolved by the Project Team are presented to the Steering Committee for resolution (Fig. 12.3).


• FIGURE 12.3. Application Implementation Committee Structure.

The project manager is responsible for managing all aspects of the project; this includes software application development, hardware, and network acquisition/readiness, as well as oversight of the interface and conversion tasks. The project manager must possess good communication, facilitation, organizational, and motivational skills when leading a successful implementation. A sound knowledge of healthcare delivery, regulatory requirements, and hospital culture, processes, and politics is essential.

Departmental Teams

The responsibility of the departmental teams is (1) to thoroughly understand the department’s information requirements and workflow, (2) to gain a full understanding of the software’s features and functions, (3) to complete a gap analysis for the new system’s capabilities with the department’s requirements, (4) to assist in the system testing effort, (5) to participate in developing and conducting end-user education, and (6) to provide a high level of support during the initial activation period of the new system. The team leaders must possess a sound knowledge of the hospital and departmental policies and procedures (both formal and informal), excellent organizational and communication skills, and must be adept at gaining consensus and resolving conflict.

Team members may change during the course of a 10to 16-month implementation. Hospital leaders, visionaries, and change agents’ participation must balance the pragmatic bottom line dictated by organizational needs (e.g., Promoting Interoperability incentives vs. patient outcomes).


During the planning phase, the problem statement and goals of the implementation are defined, committee structures established, and the organization’s requirements are defined for selecting, implementing, or upgrading an EHR or application, including the implications for regulatory compliance for safe and quality clinical practice. Commercial software developers and consultants rank this phase as the most critical factor in the selection of a system, even more important than the system itself. Optimal planning takes time and thoughtful consideration. Time spent in developing a sound plan that encompasses all the checklist steps will reduce the amount of time spent in reworking areas not reviewed during the planning phase. Plan the work and then work the plan.

The planning phase involves the following tasks:

•   Definition of committee structure

•   Definition of requirements and/or stated goal

•   Feasibility study

•   Gap analysis

•   Documentation and negotiation of project scope document

•   Development of a high-level work plan

•   Allocation of resources

Definition of the Project’s Purpose

Definition of the project’s purpose/stated goal is essential and often not readily apparent. According to Schwalbe (2016), a project should have a well-defined objective resulting in a unique product, service, or result.

The project definition includes a description of how the system will be evaluated. Establishing the evaluation criteria early in the process supports the successful management philosophy of beginning with the end in mind. The results and improvements expected from implementing the system are described by realistic goals for the system. They might include increased functionality, decreased costs, increased personnel productivity, and meeting Federal Promoting Interoperability requirements. When updating or expanding the EHR or application, the project definition includes the identification of equipment currently available, its age, the degree of amortization, and the need for hardware or operating system software upgrades prior to undertaking an upgrade project.

Feasibility Study

A feasibility study is a preliminary analysis to determine if the proposed problem can be solved by the implementation of an EHR or component application. The feasibility study not only clarifies the problem and/or stated goal but also helps identify the information needs, objectives, and scope of the project. The feasibility study helps the EHR steering committee understand the real problem and/or goal by analyzing multiple parameters and by presenting possible solutions. It highlights whether the proposed solution will produce usable products and whether the proposed system’s benefits more than justify the costs. Operational issues are reviewed to determine if the proposed solution will work in the intended environment. Technical issues are reviewed to ensure the proposed system can be built and/or will be compatible with the proposed and/or current technology. Legal and statutory regulations are reviewed to ensure compliance with local and federal law. The feasibility study includes a high-level description of the human resources required and how the selected system will be developed, utilized, and implemented. The feasibility study describes the management controls to be established for obtaining administrative, financial, and technical approvals to proceed with each phase of the project. The feasibility study seeks to answer the following questions:

•   What is the real problem to be solved and/or stated goal to be met?

•   Where does the project fit into the overall strategic plan of the organization?

•   What specific outcomes are expected from the project?

•   What are the measurable criteria for determining project success from the above outcomes?

•   What research and assumptions support the implementation project?

•   What are the known limitations and risks to the project?

•   What is the timing of the remaining phases of the project?

•   Who will be committed to implementing the project?

•   What are the estimated costs in both dollars and personnel time?

•   What is the justification for the project, including the relationship between costs and benefits?

A feasibility study includes the following topic areas.

Statement of the Objective The first step in conducting a feasibility study is to state the objectives for the proposed system. These objectives constitute the purpose(s) of the system. All objectives are outcome-oriented and are stated in measurable terms. The objectives identify the “end product” by defining what the EHR will do for the end users.

Environmental Assessment The project is defined in terms of the support it provides to both the mission and the strategic plans of the organization. The project is evaluated relative to the organization’s competition. The impact of legal, regulatory, and ethical considerations is reviewed.

Scope Management Plan The scope of the proposed system establishes system constraints and outlines what the proposed system will and will not produce. Included in the scope management plan is a description of how the team will prepare scope statement, create the work breakdown structure, verify completion of the project deliverables, and control requests for changes to the project scope. Also the criteria by which the success of the project will be judged may be included. The scope document outlines the boundaries of the project, establishes responsibilities for each team members, and sets up procedures as to how completed work will be verified and approved (Schwalbe, 2016).

Documentation and Negotiation of a Project Scope Document A project scope document is drafted by the project team and submitted to the project’s steering committee for acceptance. The project scope document includes the scope of the project, the application level management requirements, the proposed activation strategy for implementing the EHR or application, and the technical management and personnel who will implement and maintain the equipment and programs. The Scope Document is based on the findings of the feasibility study.

The project scope document becomes the internal organizational contract for the project. It defines the shortand long-term goals, establishes the criteria for evaluating the success of the project, and expands the work plan to include further detail regarding the steps to be accomplished in the development or implementation of a system or application.

Timeline A project timeline is developed providing an overview of the key milestone events of the project. The projected length of time for each major phase of the project is established. Often called a project work plan, the major steps required for project are outlined in sufficient detail to provide the steering committee background on the proposed development or implementation process.

Recommendations Committees may lose sight of the fact that not all projects are beneficial to the strategic mission of the organization. A decision can be made not only to proceed but also not to proceed with a project. The viability of the project is based on the review of the multiple factors researched in the feasibility study. It is critical to consider whether more personnel or equipment is necessary rather than more computerization. In addition to identifying potential hardware and software improvements, the costs and proposed benefits are factored into the project’s viability decision. In upgrading or considering expansion of a system, a concerted effort to maximize use of the current system and to make process improvements in the current management and coordination of existing systems should be undertaken before deciding to procure a new system(s). If, based on the findings of the feasibility study, the project steering committee determines to continue with the project, a project scope agreement is prepared.

Resource Planning

An important step in the planning phase is to determine what resources are required to successfully carry out the agreed upon project scope. A firm commitment of resources for development of the entire EHR project includes all phases of implementation and is for the system to fulfill its stated objectives. The following points should be considered when planning for resources:

•   Present staffing workload

•   Human resources (i.e., number of personnel, experience and abilities, and percentage of dedicated time to the project)

•   Present cost of operation

•   Relationship of implementation events with non-project events (e.g., The Joint Commission accreditation process, state certification inspections, peak vacation and census times, union negotiations, and house staff turnover)

•   Anticipated training costs

•   Space availability

•   Current and anticipated equipment requirements for the project team

Highly successful projects have spent the requisite amount of time to thoroughly complete the planning phase. Further, successful organizations have communicated senior management and administration’s project expectations through dissemination of the project scope document to all departments in the organization.


The system analysis phase, the second SDLC phase of developing an EHR, is the fact-finding phase. All data needs related to the requirements are defined in the project scope agreement developed in the Analysis Phase.

Key documents created in this phase are the following:

•   Gap Analysis

•   Technical requirements for hardware, software, networks

•   Functional Design Document

•   System Proposal Document

Data Collection

Only gold members can continue reading. Log In or Register to continue

Stay updated, free articles. Join our Telegram channel

Jul 29, 2021 | Posted by in NURSING | Comments Off on System Design Life Cycle: A Framework

Full access? Get Clinical Tree

Get Clinical Tree app for offline access