Explain each step of the systems development life cycle (SDLC) for a nursing informatics project. (1 page)

Chapter 9,

Introduction The following case scenario demonstrates the need to have all of the stakeholders involved from the beginning to the end of the systems development life cycle (SDLC). Creating the right team to manage the development is key. Various methodologies have been developed to guide this process. This chapter reviews the following approaches to SDLC: waterfall, rapid prototyping or rapid application development (RAD), object-oriented system development (OOSD), and dynamic system development method (DSDM). When reading about each approach, think about the case scenario and how important it is to understand the specific situational needs and the various methodologies for bringing a system to life. As in this case, it is generally necessary or beneficial to use a hybrid approach that blends two or more models for a robust development process. As the case demonstrates, the process of developing systems or SDLC is an ongoing development with a life cycle. The first step in developing a system is to understand the problems or business needs. It is followed by understanding the solution or how to address those needs; developing a plan; implementing the plan; evaluating the implementation; and, finally, maintenance, review, and destruction. If the system needs major upgrading outside of the scope of the maintenance phase, if it needs to be replaced because of technological advances, or if the business needs change, a new project is launched, the old system is destroyed, and the life cycle begins anew. SDLC is a way to deliver efficient and effective information systems (ISs) that fit with the strategic business plan of an organization. The business plan stems from the mission of the organization. In the world of health care, its development includes a needs assessment for the entire organization, which should include outreach linkages (as seen in the case scenario) and partnerships and merged or shared functions. The organization’s participating physicians and other ancillary professionals and their offices are included in thorough needs assessments. When developing a strategic plan, the design must take into account the existence of the organization within the larger healthcare delivery system and assess the various factors outside of the organization itself, including technological, legislative, and environmental issues that impact the organization. The plan must identify the needs of the organization as a whole and propose solutions to meet those needs or a way to address the issues. CASE SCENARIO Envision two large healthcare facilities that merge resources to better serve their community. This merger is called the Wellness Alliance, and its mission is to establish and manage community health programming that addresses the health needs of the rural, underserved populations in the area. The Wellness Alliance would like to establish pilot clinical sites in five rural areas to promote access and provide health care to these underserved consumers. Each clinical site will have a full-time program manager and three part-time employees (a secretary, a nurse, and a doctor). Each program manager will report to the wellness program coordinator, a newly created position within the Wellness Alliance. Because you are a community health nurse with extensive experience, you have been appointed as the wellness program coordinator. Your directive is to establish these clinical sites within 3 months and report back in 6 months as to the following: (1) community health programs offered, (2) level of community involvement in outreach health programs and clinical site–based programming, (3) consumer visits made to the clinical site, and (4) personnel performance. You are excited and challenged, but soon reality sets in: You know that you have five different sites with five different program managers. You need some way to gather the vital information from each of them in a similar manner so that the data are meaningful and useful to you as you develop your reports and evaluate the strengths and weaknesses of the pilot project. You know that you need a system that will handle all of the pilot project’s information needs. Your first stop is the chief information officer of the health system, a nurse informaticist. You know her from the health management information system mini-seminar that she led. After explaining your needs, you share with her the constraint that this system must be in place in 3 months when the sites are up and running before you make your report. When she begins to ask questions, you realize that you do not know the answers. All you know is that you must be able to report on which community health programs were offered, track the level of community involvement in outreach health programs and clinical site–based programming, monitor consumer visits made to the clinical site, and monitor the performance of site personnel. You know that you want accessible, real-time tracking, but as far as programming and clinical site–related activities are concerned, you do not have a precise description of either the process or procedures that will be involved in implementing the pilot, or the means by which they will gather and enter data. The chief information officer requires that you and each program manager remain involved in the development process. She assigns an information technology (IT) analyst to work with you and your team in the development of a system that will meet your current needs. After the first meeting, your head is spinning: The IT analyst has challenged your team not only to work out the process for your immediate needs, but also to envision what your needs will be in the future. At the next meeting, you tell the analyst that your team does not feel comfortable trying to map everything out at this point. He states that there are several ways to go about building the system and software by using the SDLC. Noticing the blank look on everyone’s faces, he explains that the SDLC is a series of actions used to develop an IS. The SDLC is similar to the nursing process, in which the nurse must assess, diagnose, plan, implement, evaluate, and revise. If the plan developed in this way does not meet the patient’s need or if a new problem arises, the nurse either revises and updates the plan or starts anew. Likewise, you will plan, analyze, design, implement, operate, support, and secure the proposed community health system. The SDLC is an iterative process—a conceptual model that is used in project management describing the phases involved in building or developing an IS. It moves from assessing feasibility or project initiation, to design analysis, to system specification, to programming, to testing, to implementation, to maintenance, and to destruction—literally from beginning to end. As the IT analyst describes this process, once again he sees puzzled looks. He quickly states that even the destruction of the system is planned—that is, how it will be retired, broken down, and replaced with a new system. Even during upgrades, destruction tactics can be invoked to secure the data and even decide if servers are to be disposed of or repurposed. The security people will tell you that this is their phase, where they make sure that any sensitive information is properly handled and decide whether the data are to be securely and safely archived or destroyed. After reviewing all of the possible methods and helping you to conduct your feasibility and business study, the analyst chooses the DSDM. This SDLC model was chosen because it works well when the time span is short and the requirements are fluctuating and mainly unknown at the outset. The IT analyst explains that this model works well on tight schedules and is a highly iterative and incremental approach that stresses continuous user input and involvement. As part of this highly iterative process, the team will revisit and loop through the same development activities numerous times; this repetitive examination provides ever-increasing levels of detail, thereby improving accuracy. The analyst explains that you will use a mockup of the hospital information system (HIS) and design for what is known; you will then create your own mini-system that will interface with the HIS. Because time is short, the analysis, design, and development phases will occur simultaneously while you are formulating and revising your specific requirements through the iterative process so that they can be integrated into the system. The functional model iteration phase will be completed in 2 weeks based on the information that you have given to the analyst. At that time, the prototype will be reviewed by the team. The IT analyst tells you to expect at least two or more iterations of the prototype based on your input. You should end with software that provides some key capabilities. Design and testing will occur in the design and build iteration phase and continue until the system is ready for implementation, the final phase. This DSDM should work well because any previous phase can be revisited and reworked through its iterative process. One month into the SDLC process, the IT analyst tells the team that he will be leaving his position at Wellness Alliance. He introduces his replacement. She is new to Wellness Alliance and is eager to work with the team. The initial IT analyst will be there 1 more week to help the new analyst with the transition. When he explains that you are working through DSDM, she looks a bit panicky and states that she has never used this approach. She has used the waterfall, prototyping, iterative enhancement, spiral, and object-oriented methodologies—but never the DSDM. From what she heard, DSDM is new and often runs amok because of the lack of understanding as to how to implement it appropriately. After 1 week on the project, the new IT analyst believes that this approach was not the best choice. As the leader of this SDLC, she is growing concerned about having a product ready at the point when the clinical sites open. She might combine another method to create a hybrid approach with which she would be more comfortable; she is thinking out loud and has everyone very nervous. The IT analyst reviews the equipment that has arrived for the sites and is excited to learn that the computers were ordered from Apple. They will be powerful and versatile enough for your needs. Two months after the opening of the clinical sites, you, as the wellness program coordinator are still tweaking the system with the help of the IT analyst. It is hard to believe how quickly the team was able to get a robust system in place. As you think back on the process, it seems so long ago that you reviewed the HIS for deficiencies and screen shots. You reexamined your requirements and watched them come to life through five prototype iterations and constant security updates. You trained your personnel on its use, tested its performance, and made final adjustments before implementation. Your own stand-alone system that met your needs was installed and fully operational on the Friday before you opened the clinic doors on Monday, 1 day ahead of schedule. You are continuing to evaluate and modify the system, but that is how the SDLC works: It is never finished, but rather constantly evolving. SDLC can occur within an organization, be outsourced, or be a blend of the two approaches. With outsourcing, the team hires an outside organization to carry out all or some of the development. Developing systems that truly meet business needs is not an easy task and is quite complex. Therefore, it is common to run over budget and miss milestones. When reading this chapter, reflect on the case scenario and in general the challenges teams face when developing systems. Waterfall Model The waterfall model is one of the oldest methods and literally depicts a waterfall effect—that is, the output from each previous phase flows into or becomes the initial input for the next phase. This model is a sequential development process in that there is one pass through each component activity from conception or feasibility through implementation in a linear order. The deliverables for each phase result from the inputs and any additional information that is gathered. There is minimal or no iterative development where one takes advantage of what was learned during the development of earlier deliverables. Many projects are broken down into six phases (Figure 9-1), especially small- to medium-size projects. Figure 9-1 Waterfall Phases Feasibility As the term implies, the feasibility study is used to determine whether the project should be initiated and supported. This study should generate a project plan and estimated budget for the SDLC phases. Often, the TELOS strategy—technological and systems, economic, legal, operational, and schedule feasibility—is followed. Technological and systems feasibility addresses the issues of technological capabilities, including the expertise and infrastructure to complete the project. Economic feasibility is the cost–benefit analysis, weighing the benefits versus the costs to determine whether the project is fiscally possible and worth undertaking. Formal assessments should include return on investment. Legal feasibility assesses the legal ramifications of the project, including current contractual obligations, legislation, regulatory bodies, and liabilities that could affect the project. Operational feasibility determines how effective the project will be in meeting the needs and expectations of the organization and actually achieving the goals of the project or addressing and solving the business problem. Schedule feasibility assesses the viability of the time frame, making sure it is a reasonable estimation of the time and resources necessary for the project to be developed in time to attain the benefits and meet constraints. TELOS helps to provide a clear picture of the feasibility of the project. Analysis During the analysis phase, the requirements for the system are teased out from a detailed study of the business needs of the organization. As part of this analysis, work flows and business practices are examined. It may be necessary to consider options for changing the business process. Design The design phase focuses on high- and low-level design and interface and data design. At the high-level phase, the team establishes which programs are needed and ascertains how they will interact. At the low-level phase, team members explore how the individual programs will actually work. The interface design determines what the look and feel will be or what the interfaces will look like. During data design, the team critically thinks about and verifies which data are required or essential. The analysis and design phases are vital in the development cycle, and great care is taken during these phases to ensure that the software’s overall configuration is defined properly. Mockups or prototypes of screenshots, reports, and processes may be generated to clarify the requirements and get the team or stakeholders on the same page, limiting the occurrence of glitches that might result in costly software development revisions later in the project. Implement During this phase, the designs are brought to life through programming code. The right programming language, such as C++, Pascal, Java, and so forth, is chosen based on the application requirements. Test The testing is generally broken down into five layers: (1) the individual programming modules, (2) integration, (3) volume, (4) the system as a whole, and (5) beta testing. Typically, the programs are developed in a modular fashion, and these individual modules are then subjected to detailed testing. The separate modules are subsequently synthesized, and the interfaces between the modules are tested. The system is evaluated with respect to its platform and the expected amount or volume of data. It is then tested as a complete system by the team. Finally, to determine if the system performs appropriately for the user, it is beta tested. During beta testing, users put the new system through its paces to make sure that it does what they need it to do to perform their jobs. Maintain Once the system has been finalized from the testing phase, it must be maintained. This could include user support through actual software changes necessitated through use or time. According to Isaias and Issa (2015), “one common trait covers all the variations of this model: It is a sequential model. Each of its stages must be entirely concluded before the next can begin” (p. 23). The main lack of iterative development is seen as a major weakness, according to Purcell (2007). No projects are static, and typically changes occur during the SDLC. As requirements change, there is no way to address them formally using the waterfall method after project requirements are developed. The waterfall model should be used for simple projects when the requirements are well known and stable from the outset. Rapid Prototyping or Rapid Application Development As technology advances and faster development is expected, rapid prototyping, also known as rapid application development (RAD), provides a fast way to add functionality through prototyping and user testing. It is easier for users to examine an actual prototype rather than documentation. A rapid requirements-gathering phase relies on workshops and focus groups to build a prototype application using real data. This prototype is then beta tested with users, and their feedback is used to perfect or add functionality and capabilities to the system (Figure 9-2). Figure 9-2 Rapid Application Development (RAD) or Rapid Prototyping According to Alexandrou (2016), “RAD (rapid application development) proposes that products can be developed faster and of higher quality” (para. 1). The RAD approach uses informal communication, repurposes components, and typically follows a fast-paced schedule. Object-oriented programming using such languages as C++ and Java promotes software repurposing and reuse. The major advantage is the speed with which the system can be deployed; a working, usable system can be built within 3 months. The use of prototyping allows the developers to skip steps in the SDLC process in favor of getting a mockup in front of the user. At times, the system may be deemed acceptable if it meets a predefined minimum set of requirements rather than all of the identified requirements. This rapid deployment also limits the project’s exposure to change elements. Unfortunately, the fast pace can be its biggest disadvantage in some cases. Once one is locked into a tight development schedule, the process may be too fast for adequate testing to be put in place and completed. The most dangerous lack of testing is in the realm of security. The RAD approach is chosen because it builds systems quickly through user-driven prototyping and adherence to quick, strict delivery milestones. This approach continues to be refined and honed, and other contemporary manifestations of RAD continue to emerge in the agile software development realm. Object-Oriented Systems Development The object-oriented systems development model blends SDLC logic with object-oriented modeling and programming power (Stair & Reynolds, 2016). Object-oriented modeling makes an effort to represent real-world objects by modeling the real-world entities or things (e.g., clinic, patient, account, nursing or healthcare professional) into abstract computer software objects. Once the system is object oriented, all of the interactions or exchanges take place between or among the objects. The objects are derived from classes, and each object is comprised of data and the actions that can be enacted on that data. Class hierarchy allows objects to inherit characteristics or attributes from parent classes, which fosters object reuse, resulting in less coding. The object-oriented programming languages, such as C++ and Java, promote software repurposing and reuse. Therefore, the class hierarchy must be clearly and appropriately designed to reap the benefits of this SDLC approach, which uses object-oriented programming to support the interactions of objects. For example, in the case scenario, a system could be developed for the Wellness Alliance to manage the community health programming for the clinic system being set up for outreach. There could be a class of programs, and well-baby care could be an object in the class of programs; programs is a relationship between Wellness Alliance and well-baby care. The program class has attributes, such as clinic site, location address, or attendees or patients. The relationship itself may be considered an object having attributes, such as pediatric programs. The class hierarchy from which all of the system objects are created with resultant object interactions must be clearly defined. The OOSD model is a highly iterative approach. The process begins by investigating where object-oriented solutions can address business problems or needs, determining user requirements, designing the system, programming or modifying object modeling (class hierarchy and objects), implementing, user testing, modifying, and reimplementing the system, and ends with the new system being reviewed regularly at established intervals and modifications being made as needed throughout its life. Dynamic System Development Method The dynamic system development method is a highly iterative and incremental approach with a high level of user input and involvement. The iterative process requires repetitive examination that enhances detail and improves accuracy. The DSDM has three phases: (1) preproject, (2) project life cycle (feasibility and business tudies, functional model iteration, design and build iteration, and implementation), and (3) postproject. In the preproject phase, buy-in or commitment is established and funding is secured. This helps to identify the stakeholders (administration and end users) and gain support for the project. In the second phase, the project’s life cycle begins. This phase includes five steps: (1) feasibility, (2) business studies, (3) functional model iteration, (4) design and build iteration, and (5) implementation (Figure 9-3). Figure 9-3 Dynamic System Development Method (DSDM) Copyright 2014 Agile Business Consortium Limited. Reproduced by kind permission. In steps 1 and 2, the feasibility and business studies are completed. The team ascertains if this project meets the required business needs while identifying the potential risks during the feasibility study. In step 1, the deliverables are a feasibility report, project plan, and a risk log. Once the project is deemed feasible, step 2, the business study, is begun. The business study extends the feasibility report by examining the processes, stakeholders, and their needs. It is important to align the stakeholders with the project and secure their buy-in because it is necessary to have user input and involvement throughout the entire DSDM process. Therefore, bringing them in at the beginning of the project is imperative. Using the MoSCoW approach, the team works with the stakeholders to develop a prioritized requirements list and a development plan. MoSCoW stands for “Must have, Should have, Could have, and Would have.” The “must have” requirements are needed to meet the business needs and are critical to the success of the project. “Should have” requirements are those that would be great to have if possible, but the success of the project does not depend on them being addressed. The “could have” requirements are those that would be nice to have met, and the “would have” requirements can be put off until later; these may be undertaken during future developmental iterations. Timeboxing is generally used to develop the project plan. In timeboxing, the project is divided into sections, each having its own fixed budget and dates or milestones for deliverables. The MoSCoW approach is then used to prioritize the requirements within each section; the requirements are the only variables because the schedule and budget are set. If a project is running out of time or money, the team can easily omit the requirements that have been identified as the lowest priority to meet their schedule and budget obligations. This does not mean that the final deliverable, the actual system, would be flawed or incomplete. Instead, because the team has already determined the “must have” or “should have” items, it still meets the business needs. According to Haughey (2010), the 80/20 rule, or Pareto principle, can be applied to nearly everything. The Pareto principle states that 80% of the project comes from 20% of the system requirements; therefore, the 20% of requirements must be the crucial requirements or those with the highest priority. One also must consider the pancake principle: The first pancake is not as good as the rest, and one should know that the first development will not be perfect. This is why it is extremely important to clearly identify the “must have” and “should have” requirements. In the third step of the project life cycle phase, known as functional model iteration, the deliverables are a functional model and prototype ready for user testing. Once the requirements are identified, the next step is to translate them into a functional model with a functioning prototype that can be evaluated by users. This could take several iterations to develop the desired functionality and incorporate the users’ input. At this stage, the team should examine the quality of the product and revise the list requirements and risk log. The requirements are adjusted, the ones that have been realized are deleted, and the remaining requirements are prioritized. The risk log is revised based on the risk analysis completed during and after prototype development. The design and build iteration step focuses on integrating functional components and identifying the nonfunctional requirements that need to be in the tested system. Testing is crucial; the team will develop a system that the end users can safely use on a daily basis. The team will garner user feedback and generate user documentation. These efforts provide this step’s deliverable, a tested system with documentation for the next and final phase of the development process. In the final step of the project life cycle phase, known as implementation, deliverables are the system (ready to use), documentation, and trained users. The requirements list should be satisfied, along with the users’ needs. Training users and implementing the approved system is the first part of this phase, and the final part consists of a full review. It is important to review the impact of the system on the business processes and to determine if it addressed the goals or requirements established at the beginning of the project. This final review determines if the project is completed or if further development is necessary. If further development is needed, preceding phases are revisited. If the project is complete and satisfies the users, then it moves into maintenance and ongoing development. The final phase is labeled “postproject.” In this phase, the team verifies that the system is functioning properly. Once verified, the maintenance schedule is begun. Because the DSDM is iterative, this postproject phase is seen as ongoing development and any of the deliverables can be refined. This is what makes the DSDM such an iterative development process. DSDM is one of an increasing number of agile methodologies being introduced, such as Scrum and Extreme Programming. These new approaches address the organizational, managerial, and interpersonal communication issues that often bog down SDLC projects. Empowerment of teams and user involvement enhance the iterative and programming strengths provided in these SDLC models. Computer-Aided Software Engineering Tools When reviewing SDLC, the computer-aided software engineering (CASE) tools that will be used must be described. CASE tools promote adherence to the SDLC process since they automate several required tasks; this provides standardization and thoroughness to the total systems development method (Stair & Reynolds, 2016). These tools help to reduce cost and development time while enriching the quality of the product. CASE tools contain a repository with information about the system: models, data definitions, and references linking models together. They are valuable in their ability to make sure the models follow diagramming rules and are consistent and complete. The various types of tools can be referred to as upper-CASE tools or lower-CASE tools. The upper-CASE tools support the analysis and design phases, whereas the lower-CASE tools support implementation. The tools can also be general or specific in nature, with the specific tools being designed for a particular methodology. Two examples of CASE tools are Visible Analyst and Rational Rose. According to Andoh-Baidoo, Kunene, and Walker (2009), Visible Analyst “supports structured and object-oriented design (UML),” whereas Rational Rose “supports solely object-oriented design (UML)” (p. 372). Both tools can “build and reverse database schemas for SQL and Oracle” and “support code generation for pre-.NET versions of Visual Basic” (p. 372). Visible Analyst can also support shell code generation for pre-.NET versions of C and COBOL, whereas Rational Rose can support complete code for C++ and Java. In addition, Andoh-Baidoo et al. found that Rational Rose “[p]rovides good integration with Java, and incorporates common packages into class diagrams and decompositions through classes” (p. 372). CASE tools have many advantages, including decreasing development time and producing more flexible systems. On the down side, they can be difficult to tailor or customize and use with existing systems. Open Source Software and Free/Open Source Software Another area that must be discussed with SDLC is open source software (OSS). An examination of job descriptions or advertisements for candidates shows that many ISs and IT professionals need a thorough understanding of SDLC and OSS development tools (e.g., PHP, MySQL, and HTML). With OSS, any programmer can implement, modify, apply, reconstruct, and restructure the rich libraries of source codes available from proven, well-tested products. As Karopka, Schmuhl, and Demski (2014) noted, Free/Libre Open Source Software (FLOSS) has been successfully adopted across a wide range of different areas and has opened new ways of value creation. Today there are hundreds of examples of successful FLOSS projects and products. . . . Especially in times of financial crisis and austerity the adoption of FLOSS principles opens interesting alternatives and options to tremendously lower total cost of ownership (TCO) and open the way for a continuous user-driven improvement process. (para. 6) To transform health care, it is necessary for clinicians to use information systems that can share patient data (Goulde & Brown, 2006; NORC, 2014). This all sounds terrific and many people wonder why it has not happened yet, but the challenges are many. How does one establish the networks necessary to share data between and among all healthcare facilities easily and securely? “Healthcare IT is beginning to adopt open source software to address these challenges” (Goulde & Brown, p. 4). Early attempts at OSS ventures in the healthcare realm failed because of a lack of support or buy-in for sustained effort, technologic lags, authority and credibility, and other such issues. “Spurred by a greater sense of urgency to adopt IT, health industry leaders are showing renewed interest in open source solutions” (Goulde & Brown, p. 5). Karopka et al., (2014) concluded that North America has the longest tradition in applying FLOSS-HC delivery. It is home of many mature, stable and widely disseminated FLOSS applications. Some of them are even used on a global scale. The deployment of FLOSS systems in healthcare delivery is comparatively low in Europe. (para. 48) Health care is realizing the benefits of FLOSS. According to Goulde and Brown (2006), “other benefits of open source software—low cost, flexibility, opportunities to innovate—are important but independence from vendors is the most relevant for health care” (p. 10). Interoperability Interoperability, the ability to share information across organizations, will remain paramount under the HITECH Act. The ability to share patient data is extremely important, both within an organization and across organizational boundaries (Figure 9-4). Figure 9-4 Interoperability According to the Health Information and Management Systems Society (HIMSS; Murphy, 2015), “an acceptable 2015 [interoperability standards] Advisory and more complete 2016 Advisory will not be achievable without the inclusion of health IT security standards” (para. 4). Few healthcare systems take advantage of the full potential of the current state of the art in computer science and health informatics (HIMSS, 2010). The consequences of this situation include a drain on financial resources from the economy, the inability to truly mitigate the occurrence of medical errors, and a lack of national preparedness to respond to natural and manmade epidemics and disasters. HIMSS has created the Integration and Interoperability Steering Committee to guide the industry on allocating resources to develop and implement standards and technology needed to achieve interoperability (para. 2). As we enter into SDLCs, we must be aware of how this type of development will affect both our own healthcare organization and the healthcare delivery system as a whole. In an ideal world, we would all work together to create systems that are integrated within our own organization while having the interoperability to cross organizational boundaries and unite the healthcare delivery system to realize the common goal of improving the quality of care provided to consumers. Summary At times during the SDLC, new information affects the outputs from earlier phases; the development effort may be reexamined or halted until these modifications can be reconciled with the current design and scope of the project. At other times, teams are overwhelmed with new ideas from the iterative SDLC process that result in new capabilities or features that exceed the initial scope of the project. Astute team leaders will preserve these ideas or initiatives so they can be considered at a later time. The team should develop a list of recommendations to improve the current software when the project is complete. This iterative and dynamic exchange makes the SDLC robust. As technology and research continue to advance, new SDLC models are being pioneered and revised to enhance development techniques. The interpretation and implementation of any model selected reflect the knowledge and skill of the team applying the model. The success of the project is often directly related to the quality of the organizational decision making throughout the project—that is, how well the plan was followed and documented. United efforts to create systems that are integrated and interoperable will define the future of health care.

Chapter 12,

Introduction

In addition to complying with federal HIPAA and HITECH guidelines regarding the privacy of patient information, healthcare systems need to be vigilant in the way that they secure information and manage network security. Mowry and Oakes (n.d.) discuss the vulnerability of electronic health records to data breaches. They suggest that as many as 77 persons could view a patient’s record during a hospital stay. It is critical for information technology (IT) policies and procedures to ensure appropriate access by clinicians and to protect private information from inappropriate access. However, authentication procedures can be cumbersome and time consuming, thus reducing clinician performance efficiency.

Physicians spend on average 7 minutes per patient encounter, with nearly 2 minutes of that time being devoted to managing logins and application navigation. Likewise, an average major healthcare provider must deal with more than 150 applications—most requiring different user names and passwords—making it difficult for caregivers to navigate and receive contextual information. Healthcare organizations must strike the right balance, in terms of simplifying access to core clinical datasets while maximizing the time providers can interact with patients without jeopardizing data integrity and security (Mowry & Oakes, n.d., para. 7).

This chapter explores use of information and processes for securing information in a health system computer network.

Securing Network Information

Typically, a healthcare organization has computers linked together to facilitate communication and operations within and outside the facility. This is commonly referred to as a  network . The linking of computers together and to the outside world creates the possibility of a breach of network security and exposes the information to unauthorized use. With the advent of smart devices, managing all of these risks has become a nightmare for some institutions’ security processes. In the past, stationary devices or computers resided within healthcare facilities. Today, smart devices travel in and out of healthcare organizations with patients, family members, and other visitors, as well as employees—both staff and healthcare providers alike. According to Sullivan ( 2012 ), “Even as they promise better health and easier care delivery, wireless medical devices (MDs) carry significant security risks. And the situation is only getting trickier as more and more MDs come with commercial operating systems that are both Internet-connected and susceptible to attack” (para. 1).

The three main areas of secure network information are (1)  confidentiality , (2) availability, and (3)  integrity . An organization must follow a well-defined policy to ensure that private health information remains appropriately confidential. The confidentiality policy should clearly define which data are confidential and how those data should be handled. Employees also need to understand the procedures for releasing confidential information outside the organization or to others within the organization and know which procedures to follow if confidential information is accidentally or intentionally released without authorization. In addition, the organization’s confidentiality policy should contain consideration for elements as basic as the placement of monitors so that information cannot be read by passersby.  Shoulder surfing , or watching over someone’s back as that person is working, is still a major way that confidentiality is compromised.

Availability refers to network information being accessible when needed. This area of the policy tends to be much more technical in nature. An accessibility policy covers issues associated with protecting the key hardware elements of the computer network and the procedures to follow in case of a major electric outage or Internet outage. Food and drinks spilled onto keyboards of computer units, dropping or jarring hardware, and electrical surges or static charges are all examples of ways that the hardware elements of a computer network may be damaged. In the case of an electrical outage or a weather-related disaster, the network administrator must have clear plans for data backup, storage, and retrieval. There must also be clear procedures and alternative methods of ensuring that care delivery remains largely uninterrupted.

Another way organizations protect the availability of their networks is to institute an acceptable use policy. Elements covered in such policy could include which types of activities are acceptable on the corporate network. For example, are employees permitted to download music at work? Restricting downloads is a very common way for organizations to prevent viruses and other malicious code from entering their networks. The policy should also clearly define which activities are not acceptable and identify the consequences for violations.

The last area of information security is integrity. Employees need to have confidence that the information they are reading is true. To accomplish this, organizations need clear policies to clarify how data are actually inputted, determine who has the authorization to change such data, and track how and when data are changed. All three of these areas use authorization and authentication to enforce the corporate policies. Access to networks can easily be grouped into areas of authorization (e.g., users can be grouped by job title). For example, anyone with the job title of “floor supervisor” might be authorized to change the hours worked by an employee, whereas an employee with the title of “patient care assistant” cannot make such changes.

Authentication of Users

Authentication  of employees is also used by organizations in their security policies. The most common ways to authenticate rely on something the user knows, something the user has, or something the user is ( Figure 12-1 ).

A © Photos.com

B

C © Gary James Calder/Shutterstock

Figure 12-1 Ways to Authenticate Users

A. An ID badge, B. Examples of weak and strong passwords, C. A finger on a biometric scanner.

Something a user knows is a  password . Most organizations today enforce a strong password policy, because free software available on the Internet can break a password from the dictionary very quickly. Strong password policies include using combinations of letters, numbers, and special characters, such as plus signs and ampersands. Some organizations are suggesting the use of passphrases to increase the strength of a password. See  Box 12-1  for an overview of best practices to create strong passwords. Policies typically include the enforcement of changing passwords every 30 or 60 days. Passwords should never be written down in an obvious place, such as a sticky note attached to the monitor or under the keyboard.

BOX 12-1 BEST PRACTICES FOR CREATING AND MANAGING PASSWORDS

DO

· Review the specific system guidelines for users—most will have information on password parameters and allowable characters.

· Use a combination of letters, numbers, special characters (!, $, %, &, *) and upper- and lowercase.

· Longer passwords are harder to crack. Consider at least 8 characters if the system allows.

· Choose a password that is based on a phrase: Use portions or abbreviations of the words in the phrase, or use substitutions (e.g., $ for S, 4 for “for”) to create the password. Example phrase: “Lucy in the Sky with Diamonds” was released in 1967; example password: LUit$wdia67.

· Think carefully about the password and create something that is easy for you to remember.

· Change your password frequently, and do so immediately if you believe your system or email has been hacked.

· Consider using a password manager program to help you create strong passwords and store them securely.

Do NOT:

· Share your password with anyone.

· Post your passwords in plain sight.

· Use dictionary words or any personal characteristics (your name, phone number, or birthday).

· Use a string of numbers.

· Use the same password for multiple sites.

Data from Pennsylvania State Information Technology Services. ( 2015 ). Password best practices. Retrieved from  http://its.psu.edu/legacy/be-safe/password-best-practices.html

The second area of authentication is something the user has, such as an identification (ID) card. ID cards can be magnetic, similar to a credit card, or have a  radio frequency identification (RFID)  chip embedded into the card.

The last area of authentication is  biometrics . Devices that recognize thumb prints, retina patterns, or facial patterns are available. Depending on the level of security needed, organizations commonly use a combination of these types of authentication.

Threats to Security

The largest benefit of a computer network is the ability to share information. However, organizations need to protect that information and ensure that only authorized individuals have access to the network and the data appropriate to their role. Threats to data security in healthcare organizations are becoming increasingly prevalent. A nationwide survey by the Computing Technology Industry Association (CompTIA) found that human error was responsible for more than half of  security breaches . Human error was categorized as failure to follow policies and procedures, general carelessness, lack of experience with websites and applications, and being unaware of new threats ( Greenberg, 2015 ). According to Degaspari ( 2010 ), “Given the volume of electronic patient data involved, it’s perhaps not surprising that breaches are occurring. According to the Department of Health and Human Services’ Office of Civil Rights (OCR), 146 data breaches affecting 500 or more individuals occurred between December 22, 2009, and July 28, 2010. The types of breaches encompass theft, loss, hacking, and improper disposal; and include both electronic data and paper records” (para. 4). The Fifth Annual Benchmark Study on Privacy & Security of Healthcare Data (Ponemon Institute, 2015) reported that “[m]ore than 90 percent of healthcare organizations represented in this study had a data breach, and 40 percent had more than five data breaches over the past two years” (para. 3). Interestingly, the most common type of data breach was related to a criminal attack on the healthcare organization (up 125% in the last 5 years). Key terms related to criminal attacks are  brute force attack  (software used to guess network passwords) and  zero day attack  (searching for and exploiting software vulnerabilities). Of the intentional data breaches (as opposed to unintentional), “45 percent of healthcare organizations say the root cause of the data breach was a criminal attack and 12 percent say it was due to a malicious insider” (Ponemon Institute, para. 4). That leaves nearly 43% of data breaches in the unintentional category. The Healthcare Information and Management Systems Society (HIMSS)  2015  survey reported the  negligent insider  as the most common source of a security breach. Examples of unintentional/negligent breaches include lost or stolen devices, or walking away from a workstation without logging off. If you use a device in your work and it is lost or stolen, or you violate policy by walking away from a workstation without logging off, this may be considered negligence and you may be subject to discipline or even lose your job. An interesting example of an unintentional data breach was reported on the OCR website: A company leased photocopier equipment and returned it without erasing the healthcare data stored on the copier hard drive, resulting in a settlement of over $1.2 million (U.S. Department of Health and Human Services, n.d.). Healthcare organizations need to be proactive in anticipating the potential for and preventing security breaches.

The first line of defense is strictly physical. A locked office door, an operating system that locks down after 5 minutes of inactivity, and regular security training programs are extremely effective in this regard. Proper workspace security discipline is a critical aspect of maintaining security. Employees need to be properly trained to be aware of computer monitor visibility, shoulder surfing, and policy regarding the removal of computer hardware. A major issue facing organizations is removable storage devices ( Figure 12-2 ). CD/DVD burners,  jump drives ,  flash drives , and  thumb drives  (which use USB port access) are all potential security risks. These devices can be slipped into a pocket and, therefore, are easily removed from the organization. One way to address this physical security risk is to limit the authorization to write files to a device. Organizations are also turning off the CD/DVD burners and USB ports on company desktops.

Figure 12-2 A Removable Storage Device

© Alex Kotlov/Shutterstock

The most common security threats a corporate network faces are  hackers ,  malicious code  ( spyware , adware,  ransomware ,  viruses ,  worms ,  Trojan horses ), and  malicious insiders . Acceptable use policies help to address these problems. For example, employees may be restricted from downloading files from the Internet. Downloaded files, including email attachments, are the most common way viruses and other malicious codes enter a computer network. Network security policies typically prohibit employees from using personal CDs/DVDs and USB drives, thereby preventing the transfer of malicious code from a personal computer to the network.

Let’s look more closely at some of these common network security threats. We typically think of hackers as outsiders who attempt to break into a network by exploiting software and network vulnerabilities, and indeed these black hat (malicious) hackers (crackers) do exist. However, more organizations are looking to employ ethical hackers (white hat hackers), those who are skilled at looking for and closing network security vulnerabilities ( Caldwell, 2011 ).

Spyware and adware are normally controlled in a corporate network by limiting the functions of the browsers used to surf the Internet. For example, the browser privacy options can control how cookies are used. A cookie is a very small file written to the hard drive of a computer whose user is surfing the Internet. This file contains information about the user. For example, many shopping sites write cookies to the user’s hard drive containing the user’s name and preferences. When that user returns to the site, the site will greet her by name and list products in which she is possibly interested. Weather websites send cookies to users’ hard drives with their ZIP code so that when each user returns to that site, the local weather forecast is immediately displayed. On the negative side, cookies can follow the user’s travels on the Internet. Marketing companies use spying cookies to track popular websites that could provide a return on advertising expenditures. Spying cookies related to marketing typically do not track keystrokes in an attempt to steal user IDs and passwords; instead, they simply track which websites are popular, and these data are used to develop advertising and marketing strategies. Nurse informaticists exploring new healthcare technologies on the Internet may find that ads for these technologies begin to pop up the next few times they are on the Internet. Spyware that does steal user IDs and passwords contains malicious code that is normally hidden in a seemingly innocent file download. This threat to security explains why healthcare organizations typically do not allow employees to download files. The rule of thumb to protect the network and one’s own computer system is to only download files from a reputable site that provides complete contact information. Be aware that malicious code is sometimes hidden in an email link or in a file sent by a trusted contact whose email has been hacked. If you are not expecting a file from an email contact, or if you receive an email with only a link in it—resist the urge to download or click!

A relatively new threat to healthcare organizations is ransomware—malicious code that blocks the organization from using their computer systems until a ransom is paid to the hacker. Consider this recent case of ransomware intrusion:

In February 2016 a hospital in Los Angeles made headlines for giving in to the ransom demand of hackers who used encryption to cripple its internal computer network, including electronic patient records, for three weeks, causing it to lose patients and money. After the hackers initially demanded $3.4 million, the hospital paid them $17,000. In explaining his decision, Allen Stefanek, president of Hollywood Presbyterian Medical Center, said, “The quickest and most efficient way to restore our systems and administrative functions was to pay the ransom.” The money was transferred through Bitcoin, a cryptocurrency that permits anonymity. ( Goldsborough, 2016 , para. 2–3)

In addition to strict policies related to network security, organizations may also use such devices as firewalls (covered in the next section) and  intrusion detection devices  to protect from hackers. Protect yourself at home by ensuring that you have an updated version of antivirus software, be wary of unusual emails, and develop strong passwords and change them frequently. If your email is hacked, report it to the proper authorities as soon as possible, warn your contacts that you have been hacked, change your password, and check to see that your antivirus software is up to date.

Another huge threat to corporate security is  social engineering , or the manipulation of a relationship based on one’s position (or pretend position) in an organization. For example, someone attempting to access a network might pretend to be an employee from the corporate IT office, who simply asks for an employee’s user ID and password. The outsider can then gain access to the corporate network. Once this access has been obtained, all corporate information is at risk. A second example of social engineering is a hacker impersonating a federal government agent. After talking an employee into revealing network information, the hacker has an open door to enter the corporate network. A related type of social engineering is  phishing . Phishing is an attempt to steal information by manipulating the recipient of an email or phone call to provide passwords or other private information.  Box 12-2  contains an example of a phishing email and tips for identifying phishing scams.

BOX 12-2 IDENTIFYING PHISHING SCAMS

Example of a Phishing Scam Email

Check suspicious emails for grammar and spelling errors, generic greetings (User, Dear, Dearest, etc.), requests for immediate action, or requests for personal information (passwords, bank account numbers). Some phishing emails may appear to come from your bank or other trusted organization. Think carefully about why a seemingly legitimate organization might be asking for information they should already have, or ask yourself why they might need to know what they are asking for. Be aware of your organization’s procedures for reporting phishing scams, and do so immediately.

Data from Pennsylvania State University Office of Information Security. (2016). Stop phishing scams. Retrieved from  http://phishing.psu.edu/what-is-phishing

Additional types of social engineering schemes include  spear phishing , which is a more specifically targeted scheme where the attacker takes advantage of contact information provided in an organization’s directory and tailors the scam email to a specific person;  baiting , where a malware-infected USB flash drive is left in a public area, thus tricking the finder into loading it to identify its owner; and  scareware , where the scam email reports that the user has been hacked and tricks them into giving the hacker remote access to the computer to “fix” it (TechTarget, n.d.).

Another example of an important security threat to a corporate network is the malicious insider. This person can be a disgruntled or recently fired employee whose rights of access to the corporate network have not yet been removed. In the case of a recently fired employee, his or her network access should be suspended immediately upon notice of termination. To avoid the potentially hazardous issues created by malicious insiders, healthcare organizations need some type of policy and specific procedures to monitor employee activity to ensure that employees carry out only those duties that are part of their normal job. Separation of privileges is a common security tool; no one employee should be able to complete a task that could cause a critical event without the knowledge of another employee. For example, the employee who processes the checks and prints them should not be the same person who signs those checks. Similarly, the employee who alters pay rates and hours worked should be required to submit a weekly report to a supervisor before the changes take effect. Software that can track and monitor employee activity is also available. This software can log which files an employee accesses, whether changes were made to files, and whether the files were copied. Depending on the number of employees, organizations may also employ a full-time electronic auditor who does nothing but monitor activity logs. More than half of healthcare organizations have hired full-time employees to provide network security ( HIMSS, 2015 ). Additional strategies for securing networks suggested in this most recent HIMSS survey were mock cyberdefense exercises, sharing information between and among healthcare organizations, monitoring vendor intelligence feeds, and subscribing to security alerts and tips from US_CERT (United States Computer Emergency Readiness Team).

Security Tools

A wide range of tools are available to an organization to protect the organizational network and information. These tools can be either a software solution, such as  antivirus software , or a hardware tool, such as a proxy server. Such tools are effective only if they are used along with employee awareness training. The 2015 HIMSS Cybersecurity Survey results indicate that an average of 11 different software tools were used by respondents to provide network security, with antivirus technology, firewalls, and data encryption as the most common tools.

For example, email scanning is a commonly used software tool. All incoming email messages are scanned to ensure they do not contain a virus or some other malicious code. This software can find only viruses that are currently known, so it is important that the virus software be set to search for and download updates automatically. Organizations can further protect themselves by training employees to never open an email attachment unless they are expecting the attachment and know the sender. Even IT managers have fallen victim to email viruses that sent infected emails to everyone in their address book. Employees should be taught to protect their organization from new viruses that may not yet be included in their scanning software by never opening an email attachment unless the sender is known and the attachment is expected. Email scanning software and antivirus software should never be turned off, and updates should be installed at least weekly—or, ideally, daily. Software is also available to scan instant messages and to delete automatically any spam email.

Many antivirus and adware software packages are available for fees ranging from free to more than $25 per month (for personal use) to several thousands of dollars per month (to secure an organization’s network). The main factors to consider when purchasing antivirus software are its effectiveness (i.e., the number of viruses it has missed), the ease of installation and use, the effectiveness of the updates, and the help and user support available. Numerous websites compare and contrast the most recent antivirus software packages. Be aware, however, that some of these sites also sell antivirus software, so they may present biased information.

Firewalls are another tool used by organizations to protect their corporate networks when they are attached to the Internet. A  firewall  can be either hardware, software, or a combination of both that examines all incoming messages or traffic to the network. The firewall can be set up to allow only messages from known senders into the corporate network. It can also be set up to look at outgoing information from the corporate network. If the message contains some type of corporate secret, the firewall may prevent the message from leaving. In essence, firewalls serve as electronic security guards at the gate of the corporate network.

Proxy servers also protect the organizational network. Proxy servers prevent users from directly accessing the Internet. Instead, users must first request passage from the proxy server. The server looks at the request and makes sure the request is from a legitimate user and that the destination of the request is permissible. For example, organizations can block requests to view a website with the word “sex” in the title or the actual uniform resource locator of a known pornography site. The proxy server can also lend the requesting user a  mask  to use while he or she is surfing the Web. In this way, the corporation protects the identity of its employees. The  proxy server  keeps track of which employees are using which masks and directs the traffic appropriately.

With hacking becoming more common, healthcare organizations must have some type of protection to avoid this invasion. An  intrusion detection system  (both hardware and software) allows an organization to monitor who is using the network and which files that user has accessed. Detection systems can be set up to monitor a single computer or an entire network. Corporations must diligently monitor for unauthorized access of their networks. Anytime someone uses a secured network, a digital footprint of all of the user’s travels is left, and this path can be easily tracked by electronic auditing software.

Offsite Use of Portable Devices

Offsite uses of portable devices, such as laptops, tablets, home computing systems, smartphones, smart devices, and portable data storage devices, can help to streamline the delivery of health care. For example, home health nurses may need to access  electronic protected health information (EPHI)  via a wireless laptop connection during a home visit, or a physician might use a smartphone to get specific patient information related to a prescription refill in response to a patient request. These mobile devices are invaluable to healthcare efficiency and responsiveness to patient need in such cases. At the very least, however, agencies should require data encryption when EPHI is being transmitted over unsecured networks or transported on a mobile device as a way of protecting sensitive information. Hotspots provided by companies, such as coffee shops or restaurants, and by airports are not secured networks. Virtual private networks (VPNs) must be used to ensure that all data transmitted on unsecured networks are encrypted. The user must log into the VPN to reach the organization’s network.

Only data essential for the job should be maintained on the mobile device; other nonclinical information, such as Social Security numbers, should never be carried outside the secure network. Some institutions make use of thin clients, which are basic interface portals that do not keep  secure information  stored on them. Essentially, users must log in to the network to get the data they need. Use of thin clients may be problematic in patient care situations where the user cannot access the network easily. For example, some rural areas of the United States do not have wireless or cellular data coverage. In these instances, private health information may need to be stored in a clinician’s laptop or tablet. This is comparable to home health nurses carrying paper charts in their cars to make home visits, and it entails the same responsibilities accompanying such use of private information outside the institution’s walls.

What happens if one of these devices is lost or stolen? The agency is ultimately responsible for the integrity of the data contained on these devices and is required by HIPAA regulations ( U.S. Department of Health and Human Services, 2006 ) to have policies in place covering such items as appropriate remote use, removal of devices from their usual physical location, and protection of these devices from loss or theft. Simple rules, such as covering laptops left in a car and locking car doors during transport of mobile devices containing EPHI, can help to deter theft. If a device is lost or stolen, the agency must have clear procedures in place to help ensure that sensitive data are not released or used inappropriately. Software packages that provide for physical tracking of the static and mobile computer inventory including laptops, smartphones, and tablets are being used more widely and can assist in the recovery of lost or stolen devices. In addition, some software that allows for remote data deletion (data wipe) in the event of theft or loss of a mobile device can be invaluable to the agency in preventing the release of EPHI.

If a member of an agency is caught accessing EPHI inappropriately or steals a mobile device, the sanctions should be swift and public. Sanctions may range from a warning or suspension with retraining to termination or prosecution, depending on the severity of the security breach. The sanctions must send a clear message to all that protecting EPHI is serious business.

The U.S. Department of Health and Human Services (n.d.) suggests the following strategies for managing remote access:

· Restricting remote access to computers owned or configured by your organization

· Disallowing administrator privileges on remote access computers

· Placing restrictions in the VPN and remote access policies

· Configuring the VPN to operate in a “sandbox” or virtual environment that isolates the session from other software running on the remote machine

· Educating users about safe computing practices in remote locations (para. 8)

To protect our patients and their data, nurses must consider the impact of wireless mobile devices (see  Box 12-3 ). Data can be stolen by an employee very easily through the use of email or file transfers.

Malware , or malicious code that infiltrates a network, can collect easily accessible data. One of the evolving issues is lost or stolen devices that can provide a gateway into a healthcare organization’s network and records. When the device is owned by the employee, other issues arise as to how the device is used and secured.

The increase in cloud computing has also challenged our personal and professional security and privacy. Cloud computing refers to storing and accessing data and computer programs on the Internet, rather than the local hard drive of a computer. Common examples of cloud computing for personal use include Google Drive, Apple iCloud, and Amazon. Cloud computing allows for easy syncing of separate devices to promote sharing and collaboration ( Griffith, 2016 ). According to Jansen and Grance ( 2011 ), cloud computing “promises to have far reaching effects on the systems and networks of federal agencies and other organizations. Many of the features that make cloud computing attractive, however, can also be at odds with traditional security models and controls” (p. vi). Healthcare organizations are moving to the cloud because cloud computing tends to be cheaper and faster, offers more flexibility for work location, provides nearly immediate disaster recovery, supports collaboration, provides security, and offers frequent software updates ( Salesforce UK, 2015 ). However, there are important security concerns related to cloud computing in health care. Guccione ( 2015 ) offers these important considerations for maintaining security in a cloud environment:

BOX 12-3 POKEMON TARGETS HOSPITAL

Informatics nurse specialists must be aware of the uses of portable devices. In 2016, one hospital in the Pittsburgh area was a site of a popular game, and the administration was upset because it creates a privacy issue for people using their hospital as a search site. This hospital actually contacted the game developer to be removed from their game.

Hospitals must always be concerned about privacy and safety issues within their control, but also be on the alert for those outside their control, such as the Pokemon Go game. Pittsburgh’s Action News 4, Marcie Cipriani, reported that Pokemon Go used West Penn Hospital, part of Allegheny Health Network in Pittsburgh, as a real-world location in the game. The game utilizes enhanced reality, which allows players to combine images from the real world with those of the game. The Allegheny Health Network officials stated that the exciting, interactive game created concerns when it brought players inside their hospital. They say hunting Pokemon at the hospital created a patient privacy issue and a safety concern. Administrators warned those who are playing to stay out of their hospitals and contacted the game’s developer, who agreed to remove their hospitals from the app. They have asked their employees to be on the lookout for anyone playing the app while they are walking around the hospital and to contact security if they see Pokemon Go players.

Data from Cipriani, M. (2016, July 30). Pokemon Go targets Allegheny Health System hospitals in Pittsburgh. Pittsburgh’s Action News 4. Retrieved from  http://www.wtae.com/news/pokemon-go-players-not-welcome-at-allegheny-health-network-hospitals/40946828

First, a cloud service should be have client-side encryption of data, which both protects files on the local hard drive as well as in the cloud. Second, a secure cloud service should offer multi-factor authentication to add an extra layer of access control for all users. Finally, a secure cloud provider should either provide data loss prevention tools to protect the stored data or allow an organization to extend its DLP protocols to the cloud. In both cases, the organization is alerted immediately the moment a user attempts to send sensitive files to an outside source. (para. 5)

It is clear that healthcare organizations need to be extra vigilant about their data security when using cloud computing. However, as we emphasized several times in this chapter, employee training on security measures may be the most important defense, because “the latest techniques for cyber theft are much less about breaching networks from the outside, such as through the cloud service, than they are exploiting holes inside an organization, particularly from careless employees” (Guccione, 2015, para. 9).

Summary

Technology changes so quickly that even the most diligent user will likely encounter a situation that could constitute a threat to his or her network. Organizations must provide their users with the proper training to help them avoid known threats and—more importantly—be able to discern a possible new threat. Consider that 10 years ago wireless networks were the exception to the rule, where today access to wireless networks is almost taken for granted. How will computer networks be accessed 10 years from now? The most important concept to remember from this chapter is that the only completely safe network is one that is turned off.  Network accessibility  and  network availability  are necessary evils that pose security risks. The information must be available to be accessed, yet remain secured from hackers, unauthorized users, and any other potential security breaches. As the cloud expands, so do the concerns over security and privacy. In an ideal world, everyone would understand the potential threats to  network security  and would diligently monitor and implement tools to prevent unauthorized access of their networks, data, and information.

Chapter 13,

Introduction The healthcare environment has grown more complex and continues to evolve every day. Unfortunately, the complexities that help clinicians to deliver better care and improve patient outcomes also take a toll on the clinicians themselves. This toll is exemplified through hours spent learning new technology, loss in productivity as the user adjusts and adapts to new technology, and unintended workflow consequences from the use of technology. Despite the perceived negative downstream effects to end users and patients as a result of technology, this very same technology can improve efficiency and yield a leaner healthcare environment. The intent of this chapter is to outline the driving forces that create the need to redesign workflow as well as to elucidate what the nurse needs to know about how to conduct workflow redesign, measure the impact of workflow changes, and assess the impact of meaningful use. Workflow Analysis Purpose According to the American Association for Justice (2016), Research has confirmed that 440,000 people die every year because of preventable medical errors. That is equivalent to almost the entire population of Atlanta, Georgia dying from a medical error each year. Preventable medical errors are the third leading cause of death in the United States and cost our country tens of billions of dollars a year. (para. 1) Not only is there an impact on patients and their families from these errors, but there is also a significant financial impact on healthcare organizations. Clearly, we must minimize these errors, and one of the most important tools for this purpose is the use of electronic health records and information systems to provide point-of-care decision support and automation. The key point is that most of these errors are preventable and we must find ways to prevent them. Technology can provide a mechanism to improve care delivery and create a safer patient environment, provided it is implemented appropriately and considers the surrounding workflow. In an important article by Campbell, Guappone, Sittig, Dykstra, and Ash (2009), the authors suggested that technology implemented without consideration of workflow can provide greater patient safety concerns than no technology at all. Computerized provider order entry (CPOE) causes us to focus more specifically on workflow considerations. These workflow implications are referred to as the unintended consequences of CPOE implementation; they are just some of the effects of poorly implemented technology. The Healthcare Information Management Systems Society (HIMSS, 2010) ME-PI Toolkit addressed workflow redesign and considered why it is so critical to successful technology implementations. Thompson, Kell, Shetty, and Banerjee (2016) stated “By partnering clinicians with informaticists we strove to leverage the power of the electronic medical record (EMR) to reduce heart failure readmissions and improve patient transitions back to the community” (p. 380). They concluded that “Partnering with clinical informatics enabled the multidisciplinary team to leverage the power of the EMR in supporting and tracking new clinical workflows that impact patient outcomes” (p. 380). This multidisciplinary team believed that their success could reshape how healthcare providers facilitate patient discharge and the transition home. Leveraging the multidisciplinary team and EMR could provide a model for patient-centered and cost-effective care that could extend beyond their patients with heart failure. Technology is recognized to have a potentially positive effect on patient outcomes. Nevertheless, even with the promise of improving how care is delivered, adoption of technology has been slow. The cost of technology solutions such as CPOE, barcode medication administration (BCMA), and electronic health records (EHRs) remain staggeringly high. The cost of technology, coupled with the lengthy timelines required to develop and implement such technology, has put this endeavor out of reach for many healthcare organizations. In addition, upgrades or enhancements to the technology are often necessary either mid-implementation or shortly after a launch, leaving little time to focus efforts on the optimization of the technology within the current workflow. Furthermore, the existence of technology does not in itself guarantee that it will be used in a manner that promotes better outcomes for patients. Given the sluggish adoption of technology, in 2009 the U.S. government took an unprecedented step when it formally recognized the importance of health information technology (HIT) for patient care outcomes. As a result of the provisions of American Recovery and Reinvestment Act (ARRA), healthcare organizations can qualify for financial incentives based on the level of meaningful use achieved. Meaningful use (MU) refers to the rules and regulations established by the ARRA. The three stages of MU were part of an EHR incentive program. During stage 1, the focus was on data capturing and sharing. Stage 2 focused on advanced clinical processes, and stage 3 sought to improve outcomes. Stage 1 was initiated during 2011–2012, stage 2 began in 2014, and stage 3 was to be launched in 2016/2017 and was intended to last through 2019 and beyond (Centers for Medicare & Medicaid Services [CMS], 2016a). However, with the new goal of paying for value and better care, the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA) reformed Medicare payments by making changes that created a quality payment program (QPP) to replace the hodgepodge system of Medicare reporting programs (CMS, 2016b; see Figure 13-1). The MACRA QPP has two paths—Merit-Based Incentive Payment System (MIPS) or Alternative Payment Models (APMs)—that will be in effect through 2021 and beyond (CMS, 2016b). The MACRA requirements for the measure development plan consist of the following: Figure 13-1 MACRA Multipayer applicability Coordination and sharing across measure developers Clinical practice guidelines Evidence base for non-endorsed measures Gap analysis Quality domains and priorities Applicability of measures across healthcare settings Clinical practice improvement activities Considerations for electronic specifications and Qualified Clinical Data Registries (QCDRs) (CMS, 2016c, p. 16). According to Hagland (2016), MACRA, MIPS, and APMs will: Allow physicians and other clinicians to choose to select the measures that reflect how technology best suits their day-to-day practice Simplify the process for achievement and provide multiple paths for success Align with the Office for the National Coordinator for Health Information Technology’s 2015 edition Health IT Certification Criteria Emphasize interoperability, information exchange, and security measures and give patients access to their information through APIs (application program interfaces) Reduce the number of measures to an all-time low of 11 measures, down from 18 measures, and no longer require reporting on the clinical decision support and CPOE measures Exempt certain physicians from reporting when EHR technology is less applicable to their practice and allow physicians to report as a group (para. 4). For an organization that seeks to meet these measures, the data to support these measures must be gathered and reported on electronically—necessitating the use of technology in all patient care areas. The successful implementation of the measurement development plan “depends on a successful partnership with patients, frontline clinicians, and professional organizations and collaboration with other diverse stakeholders to develop measures that are meaningful to patients and clinicians and can be used across payers and health care settings” (CMS, 2016c, p. 64). Many of the quality reporting measures rely on nursing and medical documentation. Most healthcare personnel already use EHRs, but MACRA measures will push healthcare organizations to reexamine the use of clinical technologies within their organization and approach implementations in a new way. Not only is there a potential for patient safety and quality issues to arise from technology implementations that do not address workflow, but a financial impact to the organization is possible as well. All organizations, regardless of their industry, must operate efficiently to maintain profits and continue to provide services to their customers. For hospitals, which normally have significantly smaller profit margins than other organizations, the need to maintain efficient and effective care is essential for survival. Given that hospital profit margins are diminishing, never has there been a more crucial time to examine the costs of errors and poorly designed workflows and the financial burden they present to an organization than now. Moreover, what are the costs to an organization that fails to address the integration of technology? This is an area where few supporting data exist to substantiate the claim that technology without workflow considerations can, in fact, impact the bottom line. Today, many healthcare organizations are experiencing the effects of poorly implemented clinical technology solutions. These effects may be manifested in the form of redundant documentation, non-value-added steps, and additional time spent at the computer rather than in direct care delivery. For example, Gugerty et al. (2007) studied the challenges and opportunities in nursing documentation and determined that it was possible to decrease the time a nurse spends documenting per shift by 25%. Technology ought not to be implemented for the sake of automation unless it promises to deliver gains in patient outcomes and proper workflow. In fact, the cost to organizations for duplicate/redundant documentation by nursing can range from $6,500 to $13,000 per nurse, per year (Clancy, Delaney, Morrison, & Gunn, 2006). Stokowski (2013) found other issues, such as systems that are slow, freeze, lose data, and “don’t dump data from monitors and screening devices into the EHR in real time” slowing the documentation process and increasing the amount of time the nurse must spend on the computer and not in direct patient care (p. 9). Examining the workflow surrounding the use of technology enables better use of the technology and more efficient work. It also promotes safer patient care delivery. The need to focus on workflow and technology is attracting increasing recognition, although there remains a dearth of literature that addresses the importance of this area. As more organizations work to achieve a level of technology adoption that will enable them to meet MACRA measures and receive financial payments, we will likely see more attention paid to the area of workflow design and, therefore, a greater body of research and evidence (AHRQ, n.d.; Qualis Health, 2011; Yuan, Finley, Long, Mills, & Johnson, 2013). Workflow and Technology Workflow is a term used to describe the action or execution of a series of tasks in a prescribed sequence. Another definition of workflow is a progression of steps (tasks, events, interactions) that constitute a work process, involve two or more persons, and create or add value to the organization’s activities. In a sequential workflow, each step depends on the occurrence of the previous step; in a parallel workflow, two or more steps can occur concurrently. The term workflow is sometimes used interchangeably with process or process flows, particularly in the context of implementations. Observation and documentation of workflow to better understand what is happening in the current environment and how it can be altered is referred to as process or workflow analysis. A typical output of workflow analysis is a visual depiction of the process, called a process map. The process map ranges from simplistic to fairly complex and provides an excellent tool to identify specific steps. It also can provide a vehicle for communication and a tool upon which to build educational materials as well as policies and procedures. One school of thought suggests that technology should be designed to meet the needs of clinical workflow (Yuan et al., 2013). This model implies that system analysts have a high degree of control over screen layout and data capture. It also implies that technology is malleable enough to allow for the flexibility to adapt to a variety of workflow scenarios. Lessons learned from more than three decades of clinical technology implementations suggest that clinical technologies still have a long way to go on the road to maturity to allow this to be possible. The second and probably most prevalent thought process is that workflow should be adapted to the use of technology. Today, this is by far the most commonly used model given the progress of clinical technology. Bucur et al. (2016) developed clinical models to support clinical decision making that were inserted into the workflow models. This system integrates a workflow suite and functionality for the storage, management, and execution of clinical workflows and for the storage of traces of execution. The knowledge models are integrated and run from the workflow to support decisions at the right point in the clinical process (Bucur et al., p. 152). The ability to track and assess decision making throughout a clinical course of care for a patient will enhance our knowledge and improve patient care. A concept that has gained popularity in recent years relative to workflow redesign is clinical transformation. Clinical transformation is the complete alteration of the clinical environment and, therefore, this term should be used cautiously to describe redesign efforts. Earl, Sampler, and Sghort (1995) define transformation as “a radical change approach that produces a more responsive organization that is more capable of performing in unstable and changing environments that organizations continue to be faced with” (p. 31). Many workflow redesign efforts are focused on relatively small changes and not the widespread change that accompanies transformational activities. Moreover, clinical transformation would imply that the manner in which work is carried out and the outcomes achieved are completely different from the prior state—which is not always true when the change simply involves implementing technology. Technology can be used to launch or in conjunction with a clinical transformation initiative, although the implementation of technology alone is not perceived as transformational. Before undertaking transformative initiatives, the following guidelines should be understood: Leadership must take the lead and create a case for transformation. Establish a vision for the end point. Allow those persons with specific expertise to provide the details. Think about the most optimal experience for both the patient and the clinician. Do not replicate the current state. Focus on those initiatives that offer the greatest value to the organization. Recognize that small gains have no real impact on transformation. Optimization Most of what has been and will be discussed in this chapter is related to workflow analysis in conjunction with technology implementations. Nevertheless, not all workflow analysis and redesign occurs prior to the implementation of technology. Some analysis and redesign efforts may occur weeks, months, or even years following the implementation. When workflow analysis occurs postimplementation, it is often referred to as optimization. Optimization is the process of moving conditions past their current state and into more efficient and effective method of performing tasks. Merriam-Webster Online Dictionary (2016) considered optimization to be the act, process, or methodology of making something (as a design, system, or decision) as fully perfect, functional, or effective as possible. Some organizations will routinely engage in optimization efforts following an implementation, whereas other organizations may undertake this activity in response to clinician concerns or marked change in operational performance. Furthermore, workflow analysis can be conducted either as a stand-alone effort or as part of an operational improvement event. When the process is addressed alone, the effort is termed process improvement. Nursing informatics professionals should always be included in these activities to represent the needs of clinicians and to serve as a liaison for technological solutions to process problems. Additionally, informaticists will likely become increasingly operationally focused and will need to transform their role accordingly to address workflow in an overall capacity as well as respective to technology. As mentioned earlier, hospitals tend to operate with smaller profit margins than other industries and these profits will likely continue to diminish, forcing organizations to work smarter, not harder—and to use technology to accomplish this goal. If optimization efforts are undertaken, the need to revisit workflow design should not be considered a flaw in the implementation approach. Even a well-designed future-state workflow during a technology implementation must be reexamined postimplementation to ensure that what was projected about the future state remains valid and to incorporate any additional workflow elements into the process redesign. Exploring the topic of workflow analysis with regard to clinical technology implementation will yield considerably fewer literature results than searching for other topical areas of implementation. More research is needed in the area of the financial implications of workflow inefficiencies and their impact on patient care. Time studies require an investment of resources and may be subject to patient privacy issues as well as the challenges of capturing time measurements on processes that are not exactly replicable. Another confounding factor affecting the quality and quantity of workflow research is the lack of standardized terminology for this area. A comprehensive literature search was conducted and published through the Agency for Healthcare Quality and Research (AHRQ) in 2008 as an evidence-based handbook for nurses; this literature search yielded findings indicating that a lack of standardized terminology in the area of workflow and publications on this topic have made it a difficult topic to support through research findings. What all organizations ultimately strive for is efficient and effective delivery of patient care. The terms efficient and effective are widely known in quality areas or Six Sigma and Lean departments, but are not necessarily known or used in informatics. Effective delivery of care or workflow suggests that the process or end product is in the most desirable state. An efficient delivery of care or workflow would mean that little waste—that is, unnecessary motion, transportation, over-processing, or defects—was incurred. Health systems such as Virginia Mason University Medical Center, among others, have experienced significant quality and cost gains from the widespread implementation of Lean development throughout their organization. Workflow Analysis and Informatics Practice The American Nurses Association (ANA), in Nursing Informatics: Scope and Standards of Practice (2015), defined functional areas of practice for the informatics nurse specialist (INS). The functional area of analysis identified the specific functional qualities related to workflow analysis. Particularly, the ANA indicated that the INS should develop techniques necessary to assess and improve human–computer interaction. Workflow analysis, however, is not relevant solely to analysis, but rather is part of every functional area the INS engages in. The functional areas covered by consultants, researchers, and other areas need to understand workflow and appreciate how lack of efficient workflow affects patient care. A critical aspect of the informatics role is workflow design. Nursing informatics is uniquely positioned to engage in the analysis and redesign of processes and tasks surrounding the use of technology. The ANA (2015) cites workflow redesign as one of the fundamental skills sets that make up the discipline of this specialty. Moreover, workflow analysis should be part of every technology implementation, and the role of the informaticist within this team is to direct others in the execution of this task or to perform the task directly. Case Study In my experience consulting, I have seen several examples of organizations that engage in the printing of paper reports that replicate information that has been entered and is available with the electronic health record. These reports are often reviewed, signed, and acted on, instead of using the electronic information. Despite the knowledge that the information contained in these reports was outdated the moment the report was printed and that the very nature of using the report for workflow is an inefficient practice, this method of clinical workflow remains prevalent in many hospitals across the United States. There is an underlying fear that drives the decisions to mold a paper-based workflow around clinical technology. There is also a lack of the appropriate amount of integration that would otherwise allow this information to be available in an electronic form. Unfortunately, many nurses find themselves in an informatics capacity without sufficient preparation for a process analysis role. One area of practice that is particularly susceptible to inadequate preparation is the ability to facilitate process analysis. Workflow analysis requires careful attention to detail and the ability to moderate group discussions, organize concepts, and generate solutions. These skills can be acquired through a formal academic informatics program or through courses that teach the discipline of Six Sigma or Lean, by example. Regardless of where these skills are acquired, it is important to understand that they are now and will continue to remain a vital aspect of the informatics role. Some organizations have felt strongly enough about the need for workflow analysis that departments have been created to address this very need. Whether the department carries the name of clinical excellence, organizational effectiveness, or Six Sigma/Lean, it is critical to recognize the value this group can offer technology implementations and clinicians. As we examine how workflow analysis is conducted, note that while the nursing informaticist is an essential member of the team to participate in or enable workflow analysis, a team dedicated to this effort is necessary for its success. Building the Design Team The workflow redesign team is an interdisciplinary team consisting of “process owners.” Process owners are those persons who directly engage in the workflow to be analyzed and redesigned. These individuals can speak about the intricacy of process, including process variations from the norm. When constructing the team, it is important to include individuals who are able to contribute information about the exact current-state workflow and offer suggestions for future-state improvement. Members of the workflow redesign team should also have the authority to make decisions about how the process should be redesigned. This authority is sometimes issued by managers, or it could come from participation of the managers directly. Such a careful blend of decision makers and “process owners” can be difficult to assemble but is critical for forming the team and enabling them for success. Often, individuals at the manager level will want to participate exclusively in the redesign process. While having management participate provides the advantage of having decision makers and management-level buy-in, these individuals may also make erroneous assumptions about how the process should be versus how the process is truly occurring. Conversely, including only process owners who do not possess the authority to make decisions can slow down the work of the team while decisions are made outside the group sessions. Team focus needs to be addressed at the outset of the team’s assembly. Early on, the team should decide which workflow will be examined to avoid confusion or spending time unnecessarily on workflow that does not ultimately matter to the outcome. In the early stages of workflow redesign, the team should define the beginning and end of a process and a few high-level steps of the process. Avoid focusing on process steps in great detail in the beginning, as the conversation can get sidetracked or team members may get bogged down by focusing on details and not move along at a good pace. Six Sigma expert George Eckes uses the phrase “Stay as high as you can as long as you can”—a good catch phrase to remember to keep the team focused and at a high level. The pace at which any implementation team progresses ultimately affects the overall timeline of a project; therefore, focus and speed are skills that the informatics expert should develop and use throughout every initiative, but particularly when addressing workflow redesign. The workflow redesign team will develop a detailed process map after agreement is reached on the current-state process’s beginning and end points, and a high-level map depicting the major process steps is finalized. Because workflow crosses many different care providers, it may be useful to construct the process map using a swim-lane technique (Figure 13-2). A swim-lane technique uses categories such as functional workgroups and roles to visually depict groups of work and to indicate who performs the work. The resulting map shows how workflow and data transition to clinicians and can demonstrate areas of potential process and information breakdowns. Figure 13-2 Example of the Swim Lane Technique Courtesy of Greencastle Associates Consulting and Atlantic Health. Reprinted by permission. It may take several sessions of analysis to complete a process map, as details are uncovered and workarounds discussed. There is a tendency for individuals who participate in process redesign sessions to describe workflow as they believe it to be occurring, rather than not how it really is. The informatics expert and/or the process team facilitator should determine what is really happening, however, and capture that information accurately. Regardless of whether a swim-lane or simplistic process map design is used, the goal is to capture enough details to accurately portray the process as it is happening today. Other techniques (aside from process mapping) may be used to help the team understand the workflow as it exists in the current state. The future-state workflow planning will be only as good as the reliability of the current state; thus it is crucial to undertake whatever other actions are needed to better understand what is happening in the current state. Observation, interviews, and process or waste walks are also helpful in understanding the current state. Value Added Versus Non–Value Added Beyond analysis of tasks, current-state mapping provides the opportunity for the process redesign team to distinguish between value-added and non-value-added activities. A value-added activity or step is one that ultimately brings the process closer to completion or changes the product or service for the better. An example of a value-added step would be placing a name tag on a specimen sample. The name tag is necessary for the laboratory personnel to identify the specimen and, therefore, its placement is an essential or value-added step in the process. Some steps in a process do not necessarily add value but are necessary for regulatory or compliance reasons. These steps are still considered necessary and need to be included in the future process. A non-value-added step, in contrast, does not alter the outcome of a process or product. Activities such as handling, moving, and holding are not considered value-added steps and should be evaluated during workflow analysis. Manipulating papers, moving through computer screens, and walking or transporting items are all considered non-value-added activities. The five whys represent one technique to drive the team toward identifying value-added versus non-value-added steps. The process redesign facilitator will query the group about why a specific task is done or done in a particular way through a series of questions asking “why?” The goal is to uncover tasks that came about due to workarounds or for other unsubstantiated reasons. Tasks that are considered non–value added and are not necessary for the purpose of compliance or regulatory reasons should be eliminated from the future-state process. The team’s purpose in redesigning workflow is to eliminate steps in a process that do not add value to the end state or that create waste by their very nature. Waste A key underpinning of the Lean philosophy is the removal of waste activities from workflow. Waste is classified as unnecessary activities or an excess of products to perform tasks. The seven categories listed here are the most widely recognized forms of waste: Overproduction: pace is faster than necessary to support the process Waiting Transport Inappropriate processing: over-processing Unnecessary inventory: excess stock Unnecessary motion: bending, lifting, moving, and so on Defects: reproduction Variation The nature of the work situation for the nurse is one of frequent interruptions causing the workflow to be disrupted and increasing the chance of error (Yuan et al., 2013). Variation in workflow is considered the enemy of all good processes and, therefore, should be eliminated when possible. Variation occurs when workers perform the same function in different ways. It usually arises because of flaws in the way a process was originally designed, lack of knowledge about the process, or inability to execute a process as originally designed due to disruption or disturbances in the workflow. Examining the process as it exists today will help with identifying variation. A brief statement about variation that cannot be eliminated: Processes that involve highly customized products or services are generally not conducive to standardization and the elimination of variation inherent to the process. Some argue that delivery of care is subject to variation owing to its very nature and the individual needs of patients. There is little doubt that each patient’s care should be tailored to meet his or her specific needs. Nevertheless, delivery of care involves some common processes that can be standardized and improved upon without jeopardizing care. Transitioning to the Future State Following redesign efforts, regardless of whether they occurred during or after an implementation or as a stand-alone process improvement event, steps must be taken to ensure that change takes hold and the new workflow continues after the support team has disbanded. Management support and involvement during the transition phase is essential, as management will be necessary to enforce new workflow procedures and further define/refine roles and responsibilities. Documentation of the future-state workflow should have occurred during the redesign effort but is not completely finished until after the redesign is complete and the workflow has become operational. Policies and procedures are addressed and rewritten to encompass the changes to workflows and role assignments. Help desk, system analyst, nursing education, and other support personnel need to be educated about the workflow specifics as part of the postimprovement effort. It is considered good practice to involve the operational staff in the future process discussions and planning so as to incorporate specifics of these areas and ensure the buy-in of the staff. When workflow changes begin to fail and workarounds develop, they signal that something is flawed about the way in which the new process was constructed and needs to be evaluated further. The workflow redesign team is then brought together to review and, if necessary, redesign the process. The future state is constructed with the best possible knowledge of how the process will ideally work. To move from the current state to the future state, gap analysis is necessary. Gap analysis zeros in on the major areas most affected by the change—namely, technology. What often happens in redesign efforts is an exact or near-exact replication of the current state using automation. The gap analysis discussion should generate ideas from the group about how best to utilize the technology to transform practice. A prudent step is to consider having legal and risk representatives at the table when initiating future-state discussions to identify the parameters within which the group should work; nevertheless, the group should not assume the existing parameters are its only boundaries. Future-state process maps become the basis of educational materials for end users, communication tools for the project team, and the foundation of new policies and procedures. Simplified process maps provide an excellent schematic for communicating change to others. Informatics as a Change Agent Technology implementations represent a significant change for clinicians, as does the workflow redesign that accompanies adoption of technology. Often the degree of change and its impact are underappreciated and unaccounted for by leadership and staff alike. A typical response to change is anger, frustration, and a refusal to accept the proposed change. All of these responses should be expected and need to be accounted for; thus a plan to address the emotional side of change is developed early on. Every workflow redesign effort should begin with a change management plan (Figure 13-3). Engagement of the end user is a critical aspect of change management and, therefore, technology adoption. Without end-user involvement, change is resisted and efforts are subject to failure. Users may be engaged and brought into the prospective change through question-and-answer forums, technology demonstrations, and frequent communications regarding change, and as department-specific representatives in working meetings. Figure 13-3 Change Management © Digital Storm/Shutterstock Many change theories have been developed. No matter which change theory is adopted by the informatics specialist, however, communication, planning, and support are key factors in any change management strategy. Informaticists should become knowledgeable about at least one change theory and use this knowledge as the basis for change management planning as part of every effort. John Kotter (1996), one of the most widely recognized change theorists, suggested the following conditions must be addressed to deal with change in an organization: Education and communication Participation and involvement Facilitation and support Negotiation and agreement Manipulation and co-optation Explicit and implicit coercion In the HIMSS (2015) Nursing Informatics Impact survey, nursing informaticists were identified as the most significant resource in a project team that influences adoption and change management. Nurses bring to such teams their ability to interact with various clinicians, their knowledge of clinical practice, and their ability to empathize with the clinicians as they experience the impact of workflow change. These innate skills differentiate the nursing informaticist from other members of the implementation team and are highly desirable in the informatics community. Nevertheless, no matter which change management techniques are employed by the informatics specialist and the project team, adoption of technology and workflow may be slow to evolve. Change is often a slow process that requires continual positive reinforcement and involvement of supporting resources. Failure to achieve strong adoption results early on is not necessarily a failure of the methods utilized, but rather may be due to other factors not entirely within the control of the informaticist. Perhaps a complete alteration in behavior is not possible, but modifications to behaviors needed to support a desired outcome can be realized. This situation is analogous to the individual who stops smoking; the desire for the cigarette remains, but the behavior has been modified to no longer sustain smoking. To manage change in an organization, nurses must modify behavior to produce the intended outcome. Change takes hold when strong leadership support exists. This support manifests itself as a visible presence to staff, clear and concise communications, an unwavering position, and an open door policy to field concerns about change. Too often, leadership gives verbal endorsement of change and then fails to follow through with these actions or withdraws support when the going gets tough. Inevitability, if leadership wavers, so too will staff. Measuring the Results Metrics provide understanding about the performance of a process or function. Typically within clinical technology projects, we identify and collect specific metrics about the performance of the technology or metrics that capture the level of participation or adoption. Equally important is the need for process performance metrics. Process metrics are collected at the initial stage of project or problem identification. Current-state metrics are then benchmarked against internal indicators. When there are no internal indicators to benchmark against, a suitable course of action is to benchmark against an external source such as a similar business practice within a different industry. Consider examining the hotel room change-over strategy or the customer service approach of Walt Disney Company or Ritz Carlton hotels, for example, to determine suitable metrics for a particular project or focus area. The right workflow complement will provide the organization with the data it needs to understand operational and clinical performance. This area is highlighted through the need for healthcare organizations to capture MACRA measures. Good metrics should tell the story of accomplishment. The presence of technology alone does not guarantee an organization’s ability to capture and report on these measures without also addressing the surrounding workflow. Metrics should focus on the variables of time, quality, and costs. Table 13-1 provides examples of relevant metrics. Table 13-1 Examples of Metrics Turnaround times Cycle times Throughput Change-over time Set-up time System availability Patient satisfaction Employee satisfaction MACRA highlights the need for healthcare organizations to collect information that represents the impact of technology on patient outcomes. Furthermore, data are necessary to demonstrate how a process is performing in its current state. In spite of the MACRA mandates, the need to collect data to demonstrate improvement in workflow— though it remains strong—is all too often absent in implementation or redesign efforts. A team cannot demonstrate improvements to an existing process without collecting information about how the process is performing today. Current-state measures also help the process team validate that the correct area for improvement was identified. Once a process improvement effort is over and the new solution has been implemented, postimprovement measures should be gathered to demonstrate progress. In some organizations, the informatics professional reports to the director of operations, the chief information officer, or the chief operations officer. In this relationship, the need to demonstrate operational measures is even stronger. Operational measures such as turnaround times, throughput, and equipment or technology availability are some of the measures captured. Future Directions Workflow analysis is not an optional part of clinical implementations, but rather a necessity for safe patient care supported by technology. The ultimate goal of workflow analysis is not to “pave the cow path,” but rather to create a future-state solution that maximizes the use of technology and eliminates non-value-added activities. Although many tools to accomplish workflow redesign are available, the best method is the one that complements the organization and supports the work of clinicians. Redesigning how people do work will evidentially create change; thus the nursing informaticist will need to apply change management principles for the new way of doing things to take hold. Workflow analysis has been described in this chapter within the context of the most widely accepted tools that are fundamentally linked to the concepts of Six Sigma/Lean. Other methods of workflow analysis exist and may become commonly used to assess clinical workflow. An example of an alternative workflow analysis tool is the use of radio frequency badges to detect movement within a defined clinical area. Clinician and patient movements may be tracked using these devices, and corresponding actions may be documented, painting a picture of the workflow for a specific area (Vankipuram, 2010). Another example of a workflow analysis tool involves the use of modeling software. An application such as ProModel provides images of the clinical work area where clinician workflows can be plotted out and reconfigured to best suit the needs of a specific area. Simulation applications enable decision makers to visualize realistic scenarios and draw conclusions about how to leverage resources, implement technology, and improve performance. Other vendors that offer simulation applications include Maya and Autodesk. Healthcare organizations need to consider how other industries have analyzed and addressed workflow to streamline business practices and improve quality outputs to glean best practices that might be incorporated into the healthcare industry’s own clinical and business approaches. First, however, each healthcare organization must step outside itself and recognize that not all aspects of patient care are unique; consequently, many aspects of care can be subjected to standardization. Many models of workflow redesign from manufacturing and the service sector can be extrapolated to health care. The healthcare industry is facing difficult economic times and can benefit from performance improvement strategies used in other industries. Although workflow analysis principles have been described within the context of acute and ambulatory care in this chapter, the need to perform process analysis on a macro level will expand as more organizations move forward with health information exchanges and medical home models. A health information exchange (HIE) requires the nursing informaticist to visualize how patients move through the entire continuum of care and not just a specific patient care area. Technology initiatives will become increasingly complex in the future. In turn, nursing informaticists will need greater preparation in the area of process analysis and improvement techniques to meet the growing challenges that technology brings and the operational performance demands of fiscally impaired healthcare organizations. Summary Meaningful use (MU) reflected the rules and regulations arising from ARRA. MACRA has changed the game and how payment will be determined. EHR adoptions “represent a small step rather than a giant leap forward” (Murphy, 2013, para. 1). Workflows integrating technology provide the healthcare professional with the data necessary to make informed decisions. This quality data must be collected and captured to meet MACRA measures. Nurses must be involved in “meaningful data collection and reporting. Documentation by nurses can tell what’s going on with the patient beyond physical exams, test results, and procedures” (Daley, 2013, para. 5). Workflow redesign is a critical aspect of technology implementation. When done well, it yields technology that is more likely to achieve the intended patient outcomes and safety benefits. Nursing informatics professionals are taking on a greater role with respect to workflow design, and this aspect of practice will grow in light of MACRA-driven measures. Other initiatives that impact hospital performance will also drive informatics professionals to influence how technology is used in the context of workflow to improve the bottom line for their organizations. In an ideal world, nurse informaticists who are experts at workflow analysis will be core members of every technology implementation team.