documentclass{book}

usepackage[skins]{tcolorbox}
tcbuselibrary{breakable}

begin{document}


newenvironment{curvebox}[1][]{parparindent12ptaddvspace{12pt plus1pt minus1pt}%
letsourceboxsource%
begin{tcolorbox}[leftrule=0pt, boxrule=0pt, rightrule=0pt, toprule=0pt, bottomrule=1pt, breakable, before upper={parindent12pt},
%colframe=black,
colback=white, colframe=black,boxrule=.5pt, arc=4mm, bottomrule at break=.5pt,toprule at break=.5pt,
rounded corners,boxsep=1.5pt,bottom=4pt, bottomsep at break=6pt, topsep at break=5.5pt,
colbacktitle=white,
coltitle=black,
 enlarge top at break by=10pt,
overlay first={
         draw[line width=1mm]; %(215:0mm) arc (215:325:0mm);% (frame.south west)--(frame.south east);
        node[anchor=north east] at (frame.south east) {vbox to 0pt{vspace*{2pt}hbox to textwidth{hfill(textit{Continued})hspace*{-5pt}}}};},
    overlay middle={
        draw[line width=.5pt]; %(215:0mm) arc (215:325:0mm);
        draw[line width=.5pt]; %(215:0mm) arc (215:325:0mm);
        %node[anchor=south west] {hspace*{-5pt}raisebox{465.5pt}{(textit{Continued})}};
        node[anchor=south west] at (frame.north west) {hspace*{-5pt}raisebox{2.5pt}{(textit{Continued})}};
        },
    overlay last={
        draw[line width=.5pt];% ([xshift=-0.5pt]215:0mm) arc (215:325:0mm);
        %node[outer sep=-20pt,anchor=south west] at (frame.north west) {};
},
]parvskip6.6ptfontsize{8.5}{10.5}selectfontnoindent{{textbf{#1}parvskip7.6pt}}noindentignorespaces%
}{parvspace*{5pt}end{tcolorbox}%
paraddvspace{9pt plus1pt minus1pt}}

chapter{Economic feasibility}

Economic feasibility cost is oftentimes the determining factor if the organization will move forward with the proposed solution. Differentiating the cost-effectiveness of the proposed solution as it relates with short- and long-term business goals can best facilitate the negotiation. Can the solution be implemented in phases allowing the organization to allocate funding incrementally?

In the instance that there will be several vendors that will be considered as part of the request for proposal, Whitten and Bentley (2007) recommend evaluating the proposal based on the following criteria


{Chapters 1} and {2} explained the projects development phase where the initiation and planning processes take place. Project management experts have varying opinion on when SDLC starts its life cycle. In searching through the literature, some authors associate the scope definition and problem identification as part of the initiating and planning phases (Whitten  Bentley, 2007). Other authors propose that SDLC coincides with the planning phase ({Williams, 2015}) while some suggests that SDLC is part of the PLC and the majority of the development starts at the execution phase. There is no absolute direction on when SDLC commences and it would vary based on the organizations own processes and methodology. Clinically, the nursing process of planning is conducted after a problem is identified and the care team agrees on a plan of care. Similarly, the SDLC is continuous wherein the systems planning of the product cycle.

Economic feasibility--cost is oftentimes the determining factor if the organization will move forward with the proposed solution. Differentiating the cost-effectiveness of the proposed solution as it relates with short- and long-term business goals can best facilitate the negotiation. Can the solution be implemented in phases allowing the organization to allocate funding incrementally?

In the instance that there will be several vendors that will be considered as part of the request for proposal, Whitten and Bentley (2007) recommend evaluating the proposal based on the following criteria

begin{curvebox}[Case Study 2.2: Patient Identification]
noindent
The standard symbols in process mapping consist of several shapes with specific use. An oval shape shows the input to start the process or the output at the end of the process. An arrow shows the direction of the process flow or step. A box or rectangle shows a task or activity being performed or executed. A diamond shape is a decision point whereby a question is asked that is answerable by either yes or no. There is only one arrow out of each activity box. If more than one arrow is needed, then it could be that a decision diamond needs to be asked. Other shapes represent a document or report, data or a subprocess (see {Figure 2.3}).

As introduced in the {Chapter 5}, flowcharts or maps play an important function in the assessment phase. As a tool, flowchart defines and provides visibility to the process by analyzing processes and/or clarifying a situation to improve knowledge and understanding of the organization. Through the use of steps and workflow sequences, relationships between steps are established in a picture representation or process map. The sequence of steps in a process, with different types of actions is displayed by boxes and other standard symbols facilitate the analysis of a solution to a given problem. This can be completed with Microsoft Visio or even in a word document if Visio is unavailable.

Scheduling current state and future state process sessions for the project team to participate through discussion and specifying each step in order will help clarify the gaps and design. The deliverable outcome of these process sessions are the flowcharts that provide knowledge on the process as a whole. This helps to bring common understanding and an awareness that users working in one part of the process must work collaboratively with those in other parts of the process so that the whole process can flow smoothly.

Reaching an understanding of the work process is part of the workflow analysis normally conducted before automating any process, information, and application of the organization. Focus groups or work groups may also be helpful for more in-depth exploration of topics that arise to better understand workflow and any potential barriers. These workgroup meetings can also discuss optimizing processes, review impacted policies, and procedures.

This analysis is focused on the physical design and integration of the software, which involves an illustration of how the application will function or work within the technical environment. The focus of the NIS in regards to technical requirements is to ask questions, raise considerations, and understand where the technical requirements impact the workflow. Identifying the system technical requirements may include hardware assessments, software features and functionality, database and reporting, as well as integration requirements. Hardware equipment needs may include desktop computers with keyboards, availability of electric outlets and cables for the additional computers, mobile workstations with computers, and connected printers for every inpatient unit, pharmacy, laboratory, radiology, and other clinical or patient care areas that would be affected. The repository and servers where the data will be held need to be taken into account before the implementation.

The infrastructure needs to be in place and invested in before the start of the project. The technical planning needs to include system maintenance once the application is operational, provision of ongoing help desk support, as well as, disaster recovery plan. Confidentiality and security of the system are important points that must be reviewed ensuring that the system is Health Insurance Portability and Accountability Act (HIPAA) compliant. It is essential to include subject matter experts such as the IT security, network, and desktop teams in the assessment phase. Technical questions have to be verified with the vendor particularly on what the system can do being that systems are deep with many layers. The technical components are the responsibility of the technical analyst that is part of the project team wherein he or she provides guidance in this process. Continuing with the same example for the blood transfusion verification project, {Table 6.6} lists examples of technical, security, and system support requirements.


This analysis is focused on the physical design and integration of the software, which involves an illustration of how the application will function or work within the technical environment. The focus of the NIS in regards to technical requirements is to ask questions, raise considerations, and understand where the technical requirements impact the workflow. Identifying the system technical requirements may include hardware assessments, software features and functionality, database and reporting, as well as integration requirements. Hardware equipment needs may include desktop computers with keyboards, availability of electric outlets and cables for the additional computers, mobile workstations with computers, and connected printers for every inpatient unit, pharmacy, laboratory, radiology, and other clinical or patient care areas that would be affected. The repository and servers where the data will be held need to be taken into account before the implementation.

The infrastructure needs to be in place and invested in before the start of the project. The technical planning needs to include system maintenance once the application is operational, provision of ongoing help desk support, as well as, disaster recovery plan. Confidentiality and security of the system are important points that must be reviewed ensuring that the system is Health Insurance Portability and Accountability Act (HIPAA) compliant. It is essential to include subject matter experts such as the IT security, network, and desktop teams in the assessment phase. Technical questions have to be verified with the vendor particularly on what the system can do being that systems are deep with many layers. The technical components are the responsibility of the technical analyst that is part of the project team wherein he or she provides guidance in this process.

This analysis is focused on the physical design and integration of the software, which involves an illustration of how the application will function or work within the technical environment. The focus of the NIS in regards to technical requirements is to ask questions, raise considerations, and understand where the technical requirements impact the workflow. Identifying the system technical requirements may include hardware assessments, software features and functionality, database and reporting, as well as integration requirements. Hardware equipment needs may include desktop computers with keyboards, availability of electric outlets and cables for the additional computers, mobile workstations with computers, and connected printers for every inpatient unit, pharmacy, laboratory, radiology, and other clinical or patient care areas that would be affected. The repository and servers where the data will be held need to be taken into account before the implementation.

The infrastructure needs to be in place and invested in before the start of the project. The technical planning needs to include system maintenance once the application is operational, provision of ongoing help desk support, as well as, disaster recovery plan. Confidentiality and security of the system are important points that must be reviewed ensuring that the system is Health Insurance Portability and Accountability Act (HIPAA) compliant. It is essential to include subject matter experts such as the IT security, network, and desktop teams in the assessment phase. Technical questions have to be verified with the vendor particularly on what the system can do being that systems are deep with many layers. The technical components are the responsibility of the technical analyst that is part of the project team wherein he or she provides guidance in this process. Continuing with the same example for the blood transfusion verification project, {Table 6.6} lists examples of technical, security, and system support requirements.


This analysis is focused on the physical design and integration of the software, which involves an illustration of how the application will function or work within the technical environment. The focus of the NIS in regards to technical requirements is to ask questions, raise considerations, and understand where the technical requirements impact the workflow. Identifying the system technical requirements may include hardware assessments, software features and functionality, database and reporting, as well as integration requirements. Hardware equipment needs may include desktop computers with keyboards, availability of electric outlets and cables for the additional computers, mobile workstations with computers, and connected printers for every inpatient unit, pharmacy, laboratory, radiology, and other clinical or patient care areas that would be affected. The repository and servers where the data will be held need to be taken into account before the implementation.

The infrastructure needs to be in place and invested in before the start of the project. The technical planning needs to include system maintenance once the application is operational, provision of ongoing help desk support, as well as, disaster recovery plan. Confidentiality and security of the system are important points that must be reviewed ensuring that the system is Health Insurance Portability and Accountability Act (HIPAA) compliant. It is essential to include subject matter experts such as the IT security, network, and desktop teams in the assessment phase. Technical questions have to be verified with the vendor particularly on what the system can do being that systems are deep with many layers. The technical components are the responsibility of the technical analyst that is part of the project team wherein he or she provides guidance in this process. %Continuing with the same example for the blood transfusion verification project, {Table 6.6} lists examples of technical, security, and system support requirements.


end{curvebox}


end{document}