8. Information systems life cycle and project management



Information systems life cycle and project management



Mary Alice Hanken and Gretchen F. Murphy


Objectives



• Define key words.


• Discuss similarities and unique characteristics among the various life cycles, including the general systems life cycle, information systems life cycle, and information systems development life cycle.


• Understand the impact on organizational resources of the juxtaposition of various information systems at different information-system life-cycle stages.


• Discuss the life-cycle stages in Nolan’s six-stage theory of information system development.


• Identify the three stages of the information systems development life cycle and the components of each.


• Apply techniques and tools, including hierarchy charts, data flow diagrams, data dictionaries, and entity-relationship diagrams, to perform information systems analysis and design.



Key words


Benefits realization


Break-even analysis


Computer-aided software engineering


Cost-benefit analysis


Cost-effectiveness analysis


Data dictionary


Data flow diagram


Data mapping


Discounted payback period


Entity-relationship diagram


General system life cycle


Group decision support software


Hierarchy chart


Information system life cycle


Joint application design


Logical system design


Payback period


Physical system design


Prototype


Request for information


Request for proposal


Return on investment


Scenario


System design


System development life cycle


Use case


Abbreviations


ADT—Admission, Discharge, Transfer


ASP—Application Service Provider


CASE—Computer-Aided Systems Engineering


CBA—Cost-Benefit Analysis


CPOE—Computerized Provider Order Entry


CPT—Common Procedural Terminology


DFD—Data Flow Diagram


EHR—Electronic Health Record


EMR—Electronic Medical Record


ERD—Entity-Relationship Diagram


FTE—Full-Time Equivalent


GDSS—Group Decision Support Software


HIM—Health Information Management


ICD-9-CM—International Classification of Diseases, Ninth Revision, Clinical Modification


ICD-10—International Classification of Diseases, Tenth Revision


IT—Information Technology


JAD—Joint Application Development


JRP—Joint Requirements Planning


PERT—Program Evaluation and Review Technique


REG/ADT—Registration/Admission, Discharge, Transfer


RFI—Request for Information


RFP—Request for Proposal


ROI—Return on Investment


Student Study Guide activities for this chapter are available on the Evolve Learning Resources site for this textbook. Please visit http://evolve.elsevier.com/Abdelhak.


When you see the Evolve logo image, go to the Evolve site and complete the corresponding activity, referenced by the page number in the text where the logo appears.


Introduction


The manager of the clinical laboratory wants to replace the department’s outdated information system to better manage information related to collecting specimens, tracking completion of laboratory tests, and reporting clinical test results. The radiology department director wants to install a speech-recognition information system to replace the current radiology dictation/transcription system as part of a new information system that will help manage patient flow, track the completion of radiology tests, store completed radiology reports, and automatically retrieve patient demographic data from the hospital information system. The vice president for hospital human resources wants to purchase an automated system that will help manage information related to employee demographics, employment status, employee benefits, and salary administration. The director of health information management (HIM) plans to request the purchase or development of a release of information system that will track requests for patient information disclosure, track patient requests for amendments, create structured letters, and provide report generation capability.


The goal of all these managers is to use automation as an adjunct in helping them better manage information. Most of these systems will cost several thousands of dollars; the clinical laboratory and radiology systems may even cost millions of dollars. Considering the investment to be made, how can these managers be reasonably confident that the systems selected will meet the needs of their organizations and their various departments? If a stand-alone or special purpose system is considered, how will it be interfaced with existing and planned systems? Is it better to identify a vendor who can offer an integrated system versus using many different vendors whose products each require an interface? How many vendors are using national standards to address interoperability questions? One strategy to help select appropriate systems is to follow a structured approach for analyzing user needs, identifying functional requirements that meet the user needs, choosing a system that has the required functionality, and implementing the system in an organized, well-thought-out manner.


Part of the health information manager’s responsibility is to help analyze, design, select, and implement automated systems for patient-related and clinical data management on a departmental and an enterprise-wide basis. If the health information manager also has oversight for or responsibilities related to health information privacy and security for their organization, his or her role also includes assuring that the organization’s privacy and security policies are addressed appropriately. This chapter outlines a structured approach for accomplishing these tasks and provides tools to assist the health information manager to be successful in this process.


Information system analysis phases


Faced with the challenge of analysis, design, selection, or development and implementation of an automated system, the health information manager’s primary goal is to provide a system that meets user or department needs and that also supports the strategic objectives of the enterprise including current and emerging privacy and security concerns. The basic system development life cycle is the process used to identify, investigate, design, select, and implement information systems. To assist in accomplishing the goal of choosing and maintaining the best systems, the information system process usually consists of six principal phases:



Taken as a whole, these phases make up what is typically called the information system life cycle.


Initiation phase


System initiation is the method through which organizations make decisions to invest in particular information systems. This leading effort is necessary to understand what is involved in replacing existing information systems and in selecting new ones. Often performed in the context of the overall information technology strategic plan for the organization, the purpose of working through an initiation process supports an integrated approach to acquiring new products and ensures a clear identification of the project scope as a starting point. Goals, a budget, a schedule, identification of system integration requirements, and a statement of the problem as understood at this point are outlined. If the organization is working with one or more vendors, then the vendors’ future system plans should be included in the process. For example, if an ambulatory care organization is using a software prescribing package that is interfaced to its electronic health record (EHR) package and the vendor selling the prescribing package decides that it will no longer support this package, then the organization will need to research and find alternatives. Alternatives may be available through the EHR vendor or other sources. It is important to consider a vendor’s financial viability. In the health care sector, a number of vendors have merged or acquired other companies. In selecting a vendor, the organization may be balancing many variables, including product support, over time. When the problem and the expectations are stated with an initial understanding, a baseline benchmark can be established against which the adjustments that always follow can be measured. The adjustments are tracked as the project progresses. Once agreement on the “problem” or the business opportunity to be addressed has been reached, then work can begin more definitively on the analysis phase. This phase affords early agreements with key users who will be valuable as the work progresses.


Analysis phase


To provide an information system that meets user requirements, the health information manager must identify how an automated system can support the performance of user tasks. In fact, understanding the environment in which user tasks are performed is an essential part of the analysis phase and provides the context to identify user needs formally. Here, the business process and associated information are documented. The analysis phase lays the foundation and provides the map for system design and implementation. This is a detailed activity that includes the review of current practices, planned processes, and the associated functional requirements so that appropriate decisions can be made. This phase is applicable for existing systems as well. Perhaps an EHR system is in place but some aspects of the system need to be improved. Perhaps the work flow of the clinicians in performing a clinical assessment does not match the flow for data capture in the electronic system or the electronic record system was initially designed on the basis of paper forms and does not take advantage of the capability of an electronic system to move recommendations or plans from the assessment to actions. For example, at the end of the history and physical or initial assessment, there are recommendations for follow-up. The recommendations might be “Obtain an orthopedic consult for left knee” or “ Schedule a chemical dependency assessment.” If these items are narrative, the system typically does not act on them. If these recommendations are data, they could easily be converted into an action that is pushed forward to begin the scheduling process.


Consideration should be given to any necessary interfaces with other systems as well. This side-by-side planning will ease the transition of system implementation. As was described in the chapter on the EHR, an organization may decide to purchase “best of breed” components. This may result in a lab system designed by one vendor, a radiology system designed by another vendor, and the core EHR designed by a third vendor. All of these components must work together and “talk” to each other.


Several tools and approaches are available to help in the analysis process. Note that some of these tools may be used in a variety of management activities beyond a systems life-cycle development process. Some of these are structured. Examples of structured development tools are graphic flow charts, decomposition charts, matrix tables, and data flow diagrams. These tools are useful in describing current practices, identifying problem areas, and mapping anticipated new processes and are discussed in more detail later in the chapter.


Although the analysis process remains the underlying activity in developing and acquiring new applications, there are alternative approaches available. One of those approaches, a less-structured approach to identifying user needs, is the use of prototype systems. In this approach, a model or “draft” system is quickly developed to provide a preliminary model or early version application. Called a prototype, the system is presented to users and refined after initial use. Before the final product is achieved using this method, there may be several iterations of the prototype. On occasion, an off-the-shelf database program may offer sufficient capability to put a prototype quickly into place. Prototyping is discussed again later in this chapter. Some organizations may use predesigned software that can be modified by in-house information technology (IT) staff. Others may contract with IT services. Another option is leasing packaged software from an application service provider (ASP). Health care organizations are making use of a variety of alternatives to keep pace with the demand for responsive information systems. The more structured process, however, is still the method of choice in most instances.


Design phase


On the basis of the findings or requirements that are identified in the analysis phase and on a decision to proceed, system design encompasses activities related to specifying the details of a new system or upgrades and additions to an existing system. Typically, this includes making decisions about the logical and physical design of the system. Through the use of structured design tools such as computer-aided software engineering (CASE) programs, a systems blueprint is developed. This blueprint is analogous to an architect’s blueprint and provides the basis for the physical system design. The physical design stage converts the system blueprint into specific detail so that computer code can be developed. In a health care setting, the traditional description of system design applies when the automated system is developed by staff within the organization. However, in today’s environment, health care organizations frequently purchase predesigned systems from outside vendors. In these cases, the meaning of system design takes on a different perspective. It usually refers to the assessment of various characteristics of the design of the system rather than the development of the system itself. The vendor system(s) must be able to produce the desired outcomes. Benchmarking with similar organizations that have the vendor’s products for similar purposes is an oft-used process.


The design component of any EHR system must include the ability to interface with other systems. Many vendors attempt to offer a complete system, but most hospitals find themselves adding components from other vendors. The costs of these interfaces should be added into project costs.


Implementation phase


System implementation involves making the system operational in the organization. Implementation characteristically covers a wide range of tasks, including the following:



To achieve the primary goal of meeting user needs, the system must function efficiently and effectively. To minimize potential system defects and operational flaws, test data are constructed and entered into the system. The results of system testing are used to correct operational weaknesses and to make programming changes. It is important to stress the system to be sure that it will perform as expected under the load of normal business operating conditions.


User training is an essential component for successful system implementation. If users are not proficient in system use, its effectiveness is reduced. The element of user training is not always sufficiently emphasized, and plans for user training are often ill conceived and incomplete. Consideration needs to be given to how to organize the training effort, identifying and selecting the most appropriate training strategies for the task and users and developing the training materials or systems. In major implementations such as EHR systems, user training is supported through available coaches who can serve as resource trainers around the clock as clinicians learn to work with new electronic tools. Also, “just-in-time” computer skills may be needed for clinicians and other staff who have limited experience with technology.


Operations/maturity phase


As the use of information systems increases in health care facilities, personnel (clinical and administrative) who use these systems grow dependent on them to do their jobs. These systems need to be reliable and available, often 24/7. Resources are often recognized and planned carefully for a new system acquisition, but it is equally important to plan resources for the operational or ongoing phase of an information system.


Although health care systems may be reliable and “down” for only short periods of time, the downtime can be extremely disruptive after all staff members have moved from paper to the electronic systems. Planning for alternative hot site data storage and restoration is vital. Tom Payne, MD, noted that causes for systems outages at the University of Washington clinical areas have been highly variable, including construction mishaps severing cables, air-conditioning system failures, users mistakenly plugging two ends of a network cable into adjacent wall ports, and denial of service attacks.1 Once in place, the information systems need to function at an optimal level. If the systems become overloaded and the response time deteriorates, it is not acceptable. Users should report slow downs and problems with the systems through a central reporting area. This area will then be able to spot trends and help determine what is needed to improve overall system performance. Some problems will likely be corrected by in-house support staff, whereas others may require the attention of the vendor.


Evaluation phase


The evaluation phase is important in any system development effort. Frequently, systems are developed and implemented but never evaluated to determine whether the original goals for implementation are met. Forgoing the evaluation stage may mean that potential system benefits are not realized. Therefore, to achieve maximum benefits realization, all systems should be evaluated against predeveloped criteria and needs requirements. After a system is in place, needs may change, users may become more sophisticated, or technology may change, so reevaluation may also start the life-cycle process over again.


Critical Thinking Exercise: Your hospital leadership team has decided to acquire a new Registration-Admission, Discharge, Transfer system. Identify and explain activities you see would benefit from an HIM viewpoint in the life cycle process about to be launched.


The players


To proceed with substantial information system projects, a number of people need to get involved. Everyone in an organization from those who are in upper-level positions who support the overall idea to those whose job may be substantially changed as the result of an implementation and, of course, those who will have a direct role in the project itself will be a player. Even projects that might initially be viewed as discrete and only involving one area of the health care organization may need to interface with other systems so the right players need to be involved in the process.



A project typically will have individuals who have an interest in the planned information system or perhaps in the existing information system. These individuals are called stakeholders. A little closer to the project are those whose budgets fund the project and who must maintain it. These individuals or departments set priorities and policies and may also use the system and are called “owners.” Individuals in upper-level positions who support the overall idea of the project are called “sponsors.”


The project will have a project manager who oversees the project. The project manager’s role is using his or her knowledge and skills and the appropriate tools and people resources to bring the pieces together in a cohesive manner to meet the goals of the project. In an information system project, the desired result is a functioning system that improves (more efficient, more effective) what it replaces and is completed within budget in a timely manner. There are excellent resources on project management and the typical responsibilities of a project manager.


The project is likely to have the following additional team roles assigned to individuals during the project phases:



• Subject matter or “domain” expert: Provides information on what is actually happening or what should happen and the information needed in the process or product under development


• Functional or “business” analyst: Captures the information from the subject matter experts, organizes it, and communicates it to the rest of the project team; lists requirements


• Solutions architect: Converts the requirements into an architecture and design for the system being created


• Development lead: Puts together the overall architecture on the basis of the work of the solutions architect and the developers


• Developer: Translates technical specifications and algorithms into executable code


• Quality assurance coordinator: Helps to develop cases and other means to test the system and verify that it will meet the needs of the customers (The entry-level role is running test cases and scripts written by another quality assurance professional.)


• Deployment coordinator: Creates a program that can live in and work within a systems environment (i.e., configure changes, identify conflicting software, manipulate other components as needed); tests all the components to make the software work in an environment


• Trainer: Creates the training materials for the users. Some of this training material may also be converted into help files and specific user instructions.2


The descriptions of these team roles are brief, but they provide a clue to the skills and related tasks involved in each role. These roles may be carried out by a combination of staff within the organization and external contractors or consultants.


Role of the health information management professional


Within a health care enterprise, the health information manager should be an advocate for use of appropriate strategies and tools that help ensure the development or selection of information systems that meet organizational needs. The health information manager usually chairs or serves on several information-related organization and department committees, for example:



As an advocate for effective system development or selection, the health information manager and key HIM specialists should assume a prominent role in the system development life cycle. Tasks assumed may vary from individual to individual, depending on specific job functions. For example, the director of an HIM department may assume overall responsibility for the analysis, design, and implementation of a departmental system. On the other hand, an HIM professional who has oversight for enterprise-wide clinical information systems may have responsibility for assisting clinical areas in carrying out the processes of the system development life cycle. The HIM manager may assume a more technical role and be responsible for direction and day-to-day operations of individual phases of the system development life cycle for a specific project. It is not unusual to see HIM managers leading project development and implementation teams for a variety of clinical and patient-related information systems. As noted in the list of project roles, the HIM professional could serve as a subject-matter expert, a functional analyst, a quality assurance analyst, or a trainer. Once again, the interests and specific background of the HIM professional will determine roles in any given project.


image


Project management


One of the crucial factors for ensuring the success of any project is the degree to which it is effectively managed. The information systems life cycle is no different from any other project. Success requires good planning, appropriate allocation of resources, and effective monitoring and control. Information system project managers may have a technical background or a management background.


The first step in project management is development of the project plan. One of the most crucial elements of the plan is the definition of the scope of the project. Identifying project scope identifies the boundaries of the project. For example, the scope of development and implementation of an order-entry system would include considerations of interfacing with the clinical record, laboratory, radiology, and pharmacy systems but would not include concerns with interfacing with a release of information tracking system. In the case of implementing a computerized provider order entry (CPOE) module for the clinical record system, the team would include physicians, nurses, and other care providers who would be users of the system as well as those individuals representing the systems and functional areas needed to bring the project to successful completion. If the project scope includes developing structured text for progress notes in either the inpatient or outpatient arenas, then the team would include physicians, nurses, other care providers and the health information manager or health information specialist.


A second crucial component of the planning phase is identification of project deliverables and activities. A deliverable is a tangible work product such as a computer code, documents, system specifications, a database design, and so on.


After deliverables have been delineated, activities to support deliverable development must be identified. Good project management relies on breaking down the project into smaller and smaller activities. Frequently, a tool called the work breakdown structure is used to break the project into smaller and smaller activities. An example of a work breakdown structure appears in Table 8-1.



When activities have been identified, resources must be allocated to the project. Resources include budget, personnel, equipment, and materials. Part of resource allocation is identification of the project team and each team member’s role and responsibilities. As is evident in the activities outlined in the database work breakdown structure in Table 8-1, many skill sets are needed to ensure that the project is efficiently completed. Individuals included as part of the team in this project would be systems analysts, database administrators, data administrators system managers, technical writers, users, domain experts, and managers.


In addition to personnel, project resources include equipment, facilities, and materials. In the database project in Table 8-1, equipment would include computers, case tools, and printers. Facilities could include telephones and office and meeting space. Materials could include such things as office supplies and reference materials. Thus, a significant part of project planning includes identification of project deliverables, activities, and resources necessary for efficient project completion. These elements directly contribute to the development of the project budget.


After deliverables, activities, resources, and budget are established for the program, a project schedule must be developed. The schedule incorporates project activities and personnel, identifying who will perform the activity and when the activity will be completed. Several project management software programs are available. Most of these programs include project scheduling tools such as Gantt charts and other tools such as flow charts and visuals to help track the deliverables and progress of the project. These methods are described in other sections of this text.



When a project schedule has been completed, with deadlines, milestones, and personnel identified, the project manager can allocate resources to the project. This includes allocation of money, space, facilities, equipment, and people to the project. The project manager must ensure that there is appropriate resource leveling. This means that resources are appropriated only at the point in the project at which they are actually needed. Projects frequently exceed budget projections because personnel, equipment, materials, or facilities are allocated too far in advance of their need. On the other hand, project budgets can be exceeded when resources are allocated too late, thus holding up vital project activities.


Monitoring and control of the project are crucial components of the project manager’s job. If the project is not adequately monitored and controlled, disastrous results may occur. Monitoring and control include tracking the schedule of the project and also include active intervention should the project either fall behind or exceed schedule. The project manager must be able to foresee problems and then readjust and allocate resources appropriately to ensure that deliverables are on time and within budget.


image


Critical Thinking Exercise: Your hospital has an electronic health record that has been in operation for several years. The oversight team has identified a project to assess he overall system of templates used for data capture across the services. You have been identified as a subject matter expert and asked to manage this project. Prepare a 2 page preliminary project plan that reflects how you will apply the information just explained.


System life cycles


To appreciate fully the development of a system and its place within the organization, knowledge of the life cycle of systems is necessary. Like human beings, all systems go through a life cycle. Systems originate, develop, and, finally, decline. Several models have been developed that illustrate the concept of a system life cycle. In this section, four perspectives of system life cycles are discussed.



General system life cycle


Information systems are similar to biological, social, and political systems. All systems go through a system life cycle. All systems have a birth or development period, a period of growth, a period of maturity, and a period of decline or deterioration.3 The following example demonstrates the four phases of the general system life cycle.




Example of the Phases of the General System Life Cycle


Birth and development (phase 1)


Ten years ago, the health information department of a community hospital implemented a system to track the release of information from patient records. The goal of the system was to allow health record employees to document the requests for information, the verification of those requests (as needed), and the description of the documents copied/released—to whom, why, when, and whether there was a charge associated with completing the request. The system was primarily a departmental system to meet the needs of this 300-bed facility.


Growth and maturity (phases 2 and 3)


In the intervening years, the hospital has formed several alliances that have broadened the scope of the services provided, and the laws related to release of patient-identifiable information have changed. Among the hospital changes is the expansion of outpatient services through acquisition of several clinics in the community, the addition of an outpatient surgery facility, and alliances with substance abuse, rehabilitation, and skilled nursing facilities. At first, the release-of-information tracking system was able to expand to keep pace with the institution’s growing needs. However, as the hospital evolved into a health care enterprise, the needs for tracking and monitoring have changed. In addition, related laws have changed. For example, the Health Insurance Portability and Accountability Act and many state laws have specific regulations related to release of personally identifiable health information. In building the needed release-of-information tracking system, the organization will need to evaluate all the current and pertinent federal and state laws that apply to their particular organization. The HIM professional should take the lead in this endeavor.


Decline (phase 4)


The current release-of-information tracking system, which was designed primarily for internal departmental use, does not meet today’s need for a more comprehensive, updated, enterprise-wide distributed system. The organization, or “enterprise,” now has more components, perhaps with different rules related to release of information, for example, general health versus mental health or radiology images. The organization also has more “doors” through which information might be released. The formal release of information practices may be well understood, but clinical and administrative staff may not recognize disclosure of information that occurs through secure e-mail or staff who have access to electronic clinical reports and receive what appears to be a legitimate request for information. Tracking of release of information, including to whom, what was released, and for what purpose are part the formal HIM department routine but may not occur if information is released through the many other doors that are now available in the organization or enterprise.


Information system life cycle


As the preceding release of information tracking example illustrates, information systems have a life cycle that is analogous to the general system life cycle. To be more definitive in describing what occurs at each phase in the information system life cycle, more descriptive labels are attached to each phase.3



For example, in the information system life cycle, the development phase of the general system life cycle is usually referred to as the design phase. This is the phase in which analysis of the requirements and design of the information system occurs. The general system life cycle growth phase is normally called the implementation phase. In this phase, development, testing, and implementation take place. The operation/maintenance activity of the information system life cycle is similar to the maturity phase of the general system life cycle. This is the functioning phase of the system in which activities to maintain, update, and operate the system occur. The fourth phase of deterioration or decline is identified in the information system life cycle as system obsolescence. Figure 8-1 shows a comparison between the phases of the general system and the information system life cycles.



The time over which each phase occurs varies from system to system. Large, complex systems may take months to years to design, whereas simpler, smaller systems may take a few weeks to design. The length of time over which a system can meet user needs depends on many variables. Sometimes these variables include a change in work volume, a change in strategic organizational objectives, a change in the type of work performed, or a change in the available technology. As the preceding release of information tracking system example illustrates, the system became obsolete because it could not accommodate a larger volume, different rules, and a broader range of users in a distributed environment.


Information system life cycles in the organization


An organization is composed of hundreds and perhaps thousands of interacting and interfacing information systems. For example, in a health care facility, there are information systems that support clinical functions, such as those that provide order entry, clinical monitoring, nursing care, dietary requirements, rehabilitation needs, and diagnostic testing. There are also information systems that support administrative functions, such as patient registration, billing, marketing, and human resources. All these systems use some type of IT to assist them in carrying out their functions. Given the number of information systems in any organization, it is easy to recognize that at any one time, multiple information systems are in different phases of an information system life cycle. For example, the clinical laboratory system may be in the maintenance phase of the information system life cycle, whereas the radiology information system is in the design phase of the information system life cycle. On the other hand, the HIM department tracking system for release of information may be in the implementation phase, whereas the marketing information system is in the obsolescence phase. Thus, information systems throughout an enterprise are in a constant state of fluctuation (Figure 8-2).



It is unlikely that at any given time, all organization information systems would be in a state of maturity. It is more likely that there will consistently be a significant level of variability in information system life cycles. Even when an organization purchases an integrated clinical and administrative system, the system will have a number of modules, and within the modules there may be basic and more advanced functionality or the organization may decide to implement three of the modules initially and then add other modules later. Therefore, the components of an integrated system may still be in different phases of the systems life cycle. Figure 8-2 shows the concept of information system fluctuation. It is important for the health information manager to recognize this variability because this phenomenon of discontinuity causes stress within the organization. This stress can be manifested in multiple ways. One aspect of stress is the competition for resources. There is competition for similar resources, including technical assistance (people) during approximately the same period (time) and use of the same hardware (equipment) resources. There is also competition for financial allocation (budget). The HIM department needs technical assistance and training during the implementation stage of the release of information tracking system. The HIM department will then train other users in the organization. The clinical laboratory needs technical assistance in identifying system design. The human resources system requires technical expertise to perform the upgrade and may require a greater portion of the equipment resource. As in the illustration in Figure 8-2, the systems, although in various stages of their cycles, are all bearing some cost in regard to financial expenditures of the organization. Prioritization of needs and suitable allocation of resources are exceedingly important to meet organizational needs. It is, however, a significant challenge for the organization to balance the allocation of resources appropriately so that maximum benefit is realized. Resource balancing includes competing clinical needs to support improved patient care. It may be that some of these need converge and can be supported through improved information systems.


Aggregate information life cycle of the organization


A logical question that might arise after the discussion of information system life cycles is whether the organization as a whole has a life cycle of its own. In other words, can a composite picture of an organization-wide information system life cycle be visualized if all information system life cycles are aggregated into a whole? This is an appropriate question because an organization’s level of experience and sophistication with IT has an impact on how it manages the technology. For example, an organization that is just starting to automate its information functions would have a different emphasis in management of its technology than an organization in which most of the information functions were already automated.


Nolan4 first described the concept of organizations that have information system life cycles. The view postulated by Nolan is that an organization at any given point in time is at a certain maturity or level of sophistication in deployment of IT. Nolan postulated the following stages in his organization-wide information system process:



At each of these stages, the organization usually takes a different approach to management of IT. For example, in the early stages of initiation and expansion, the organization is likely to assume a laissez-faire attitude, allowing expansion of the technology with little or no organization-wide control. For example, a clinician in a particular clinic may develop a small system that works well within that clinic. In the meantime, the organization is looking for an electronic record system that will meet the needs of its ambulatory services. After the organization makes a decision to move forward with an organizational approach, the clinic with its own system will be expected to participate in the organization-wide system. Resources will be redirected to the organizational system.


As the growth of technology expands, the organization becomes most concerned with budget, allocation of funds for technology expansion, and centralizing resources. In other words, the organization tries to gain control over the resources. As time goes on, the organization becomes more sophisticated in its management of the technology. The organization grows to realize the need for integration of technology and information management. In the stages of integration and data administration, the organization treats information and its associated technologies and management as critical to the survival of the organization. The main focus in these stages is to distribute functions but also to centralize standards for both technology and information management. In the final stage, maturity, the organization views information as a strategic resource and emphasizes development of applications that further the strategic advantage of the enterprise. At this point in development, the organization’s IT planning will align with the business strategic plans. If the strategic plan includes a major new purchase, resources may or may not be allocated to continue support for the older IT system. The new technology and its advocates are competing with maintenance needs of the older system and its advocates.


Although it is important to understand that individual information systems have their own life cycles, it is equally important to recognize that an enterprise will also be at a certain stage of IT management maturity. Being able to identify an enterprise’s point in its life cycle helps explain why certain policies exist or why specific strategies are deployed. For instance, if a health information manager works in an organization that is in the integration stage of the life cycle, he or she would likely have been part of developing centralized standards. This might be in areas related to the type of communication protocols, electronic signature tools, template management, or documentation amendment approaches that are allowed. On the other hand, if the health information manager is employed in an organization in which technology is newly implemented, there may be few policies and procedures that help to direct information growth. Understanding at which stage of maturity an organization is in the information life cycle helps the health information manager play a more effective role in the organization’s information system process. The ability of the health information manager to identify, analyze, organize, and write and revise the necessary overarching policies as a system is deployed is a critical skill. Frequently, these policies are influenced by laws, regulations, and standards as well as the specific needs of the organization.


image


Information systems become obsolete for several reasons. A system may be obsolete because it uses older technology that cannot meet current information-processing demands. The use of older technology in itself does not necessarily mean that the information system is obsolete. Rather, it is whether technology meets required needs that determines obsolescence. Systems can also become obsolete because they cannot handle an increase in the volume of data or cannot handle more sophisticated data management tasks. Systems frequently become obsolete because they do not support the strategic objectives of the organization. The release of information tracking system described in the first part of this chapter is a good example. The strategic objective of the organization in that example was to provide a broader range of services at multiple, diverse sites. Because of the change in strategic objectives to include multiple distributed sites and the changes in the laws, the release of information tracking system could not meet the needs of the organization. Common examples of systems that quickly become obsolete are those in the area of administrative decision support. Decision support systems provide a variety of tools that help management in making decisions about semistructured and unstructured problems. Because the health care environment marketplace is changing at such a rapid pace, there is a need for accurate, reliable, and user-friendly decision support systems. Many decision support systems and their associated tools are not flexible enough to meet current demands for information access and analysis and quickly become outdated. As International Classification of Diseases, Tenth Revision (ICD-10) is implemented in the United States, the International Classification of Diseases, Ninth Revision, Clinical Modification (ICD-9-CM) coding systems will be completely redesigned. Clinical decision support systems are also used to help make decisions about patient care. Some of these systems provide basic alerts, whereas others are very sophisticated. Again these systems require tending and rely on quality data. This is a growing area of health information systems, and today’s expectations of EHR systems include the integration of real-time EHRs and clinical decision support tools. For example, as medications are ordered the clinical decision support tools can cross-check interactions with other medications already prescribed for a patient, check patient allergies, and flag potential orders for review. These decision support systems need to be updated regularly on the basis of determinations of quality-of-care profiles.


Sometimes information systems become obsolete because of a change in user expectations. For example, a hospital-wide information system may provide the necessary functionality for nursing care, but users expect the functionality to be enhanced in some way. The users might expect to be able to take their computer device with them, perhaps in their pocket rather than having to enter data at a central nursing station/terminal. An EHR systems may not take advantage of all the interactive capabilities possible after the record is a database instead of narrative forms. Perhaps follow-up and patient reminders were not built into the system or the system does not have a smart feature that notes that for patients of a given age or sex, certain exams are due.


As organizations work to advance health information exchange, new requirements for wide-area networks require a technology infrastructure that allows access from multiple external locations. Even a single user wants to be able to work from home or use wireless technology to check on information. Many organizations have multiple work sites, and even if this is not the case, health care providers are distributed. Care providers may be visiting a patient at home or simply working from an off-site location. All of this capability must be provided within the bounds of confidentiality and security of protected health information.


At the level of the user interface, another system improvement might elect to use color on the display screen to alert clinical providers to out-of-range laboratory values rather than using asterisks to mark such values. Or because clinicians who copy and paste within an EHR’s electronic progress notes do not always provide appropriate attribution to the original author, automatically adding color to copied text is a way to alert the reader that the original text can be found elsewhere in this patient’s record. Or because certain information may be pulled forward into a note by design, the information added to this visit or progress notes is highlighted in a different color. As users become more sophisticated about how information systems can help them perform their daily tasks more optimally and experience new ways to view data on workstations or on their handheld devices, they are likely to expect system enhancements.


In addition to changes in technology, operational functions, strategic objectives, and user expectations, information systems may become obsolete because they simply wear out—in other words, break down. Mechanical failures with storage devices, input devices, output devices, or processing components are more likely to occur as the system grows older.


image


Information system life cycle


Principles for system development


The information systems life cycle is presented as a formal process. Everyone who undertakes a system development project wants to succeed. Therefore, discussions with colleagues and thorough research of existing systems—both highly successful and those that struggled or failed—provide information for the planning and assessment process. Whitten et al.5 suggest eight principles to use with the systems approach and technologies:



As a system project emerges, it is recommended that the first phase, the initiation phase, not be skipped or taken lightly. This phase is the opportunity not only to reaffirm that the project should go forward but also to examine carefully the problems, any significant reasons for proceeding, and opportunities that occur as a result of having the system in place.5 This is the time to set out project scope and objectives accompanied by a narrative to give context. Prepare a preliminary plan with an initial time table to be presented and negotiated. Assess the value of the project; the value may be monetary, or it may be stated in other terms. This work should lead to a consensus related to the project, everything from “proceed to the next phase” to the “priority problems are . . . .”


Problem analysis basics


Individuals may intuitively know that automating a problem will not fix it; therefore, business process redesign should be applied to address and resolve problems first, wherever possible, and then identify where the application of automation makes sense. Many of the quality improvement principles and tools can be used to make improvements to the processes in an organization before the formal systems design process. Doing the process improvement work first will help focus more clearly on how and where to apply automation to the problem.


After the initial phase, the work proceeds to the next phase. Although there may be variation among authors about the names of these steps, the process usually encompasses the areas of analysis, design, implementation, and evaluation. Although the steps in the development life cycle are primarily concerned with new development efforts, they are equally appropriate with some modification for selection of already developed products from the vendor market. Because this chapter is concerned with the HIM professional’s role in systems development, there is an emphasis on tasks associated with analysis, selection, implementation, operations, and evaluation support activities and a de-emphasis on purely technical activities associated with each process. The focus in the design area is more conceptual than technical and concentrates on issues that relate to general system design principles and user interface concerns associated with input and output media.


Users tend to interact with the presentation layer of a software application, but in addition to the presentation layer, there is a business logic layer and a data access layer. It might be helpful to think of the application as an iceberg and as the presentation layer the part of the iceberg that is visible above water. It may be the smallest portion of the iceberg because the business logic layer contains the programmed business rules and the data access layer contains the rules related to the storage and access of information along with the logic to navigate the database. The data access layer also contains the definitions of the data tables (Figure 8-3).



Analysis


The development or selection of an information system can be an arduous and complex process. In the face of the challenge of information system development, a logical question that arises is, “Where should we begin?” The beginning of any development project effort usually starts with a perceived need or an effort to solve a problem. For example, a supervisor in the HIM department may recognize that a new information system for case mix analysis may provide improved decision support capabilities. Or a perceived need may arise when a current information system, such as the release of information tracking system, enters the obsolescence phase of the information system life cycle. The launching of the development process may also be initiated by users who believe that new technology is required to support their daily tasks. Whatever the reason for initiation, the goal of the analysis step is to build on the initial work and determine the feasibility of a new system and confirm the scope of the developmental or selection effort. In this context, the analysis will confirm or determine the following:



Many organizations have invested considerable resources into a system or into modules in a large system. The organization may be working with one or more vendors to support an organization-wide system such as an EHR system. Vendors typically want to keep their customers and want to know whether their system or a module within it is not meeting customer needs. Some fixes may be fairly easy, and the vendor is happy to incorporate the changes into its next system upgrade. Other fixes may require substantial redesign. An organization that is clear about its needs and expectations and has used a systems analysis approach should be able to communicate with vendor development staff. If a vendor is not able to meet the organization’s needs, then the organization may explore alternatives.


Tools and AIDS for system analysis


Health information professionals have many tools at their disposal to assist in determining the feasibility and scope of any new information system development effort. These tools are appropriate to use whether the system is being developed internally by the organization or will be purchased from a vendor. Several tools5–7 are used in systems analysis, including the following:



The use of each of these tools depends on the desired output from the analysis and analyst preference. In this chapter, only selected tools are discussed. Table 8-2 lists selected tools and gives a brief description of their purpose.



Decomposition diagrams—hierarchy chart


The hierarchy chart is a type of decomposition diagram. Its purpose is to break down problems into smaller and smaller detail. The hierarchy chart does this by identifying all the tasks in a process and grouping them into various hierarchical levels. The hierarchy chart is organized in a treelike manner. Each task in the chart is called a node. Each node, except for the uppermost one, has a single parent node. Each parent node may have none, one, or multiple children nodes. Sibling nodes are nodes that are all on the same level of the chart. The lowest nodes on each level of the chart (i.e., nodes that have no children) are called functional primitives. The functional primitive nodes are eventually translated into program modules that perform the work of the system.


To construct a hierarchy chart, the first step is to list all the tasks in the order in which they occur.


To develop a tree structure, it is necessary to assemble the processes together in functionally similar groups. Why would an HIM professional want to develop a hierarchy chart? Whether the information system under consideration is to be developed in house or purchased from a vendor, a hierarchy chart of the system should be developed for the following reasons:




The chart provides a means to communicate with developers and can also be used to assess whether a vendor product will meet user needs.


image


Data flow diagrams/process modeling


After tasks within a system are identified, it is necessary to expand this information into a data flow diagram (DFD). DFDs are used to track the flow of data through an entire system. The DFD answers the question, “Now that the basic processes are defined, what data is needed for the processes to be carried out?” DFDs identify the data flow within a system, in essence providing a data map of which data go from an area, which data are received by an area, and which data are either temporarily or permanently stored in an area. In addition to tracking data flow, a DFD identifies transformations on data (processes) and data repositories (data stores).


There are four essential concepts related to DFDs: external entities, processes, data stores, and data flows. An external entity includes people or groups of people who interact with the system but are not internal to it. For example, a patient would be considered an external entity to a system of health care delivery. Processes are actions performed on data. Data stores are repositories for data. They may be either temporary or permanent storage areas. Data flows represent the movement of data through a system. Data move out of entities, to entities, between processes, and into and out of data stores.



Specific symbols are used to identify each DFD component. The external entity is represented by a square. Table 8-3 displays DFD symbols with examples of each. Like the hierarchy chart, DFDs are constructed by moving from the complex to the simple. In other words, the system as a whole is first represented, and successive levels represent more and more system detail. The method and construction rules for developing DFDs vary, depending on whose recommended process is followed. The description and construction of DFDs in this chapter follow general development rules. For readers with an additional interest in developing a greater depth of tool usage, appropriate references are provided.5–7



The context level of the DFD provides a relatively simple picture of the system under study. The context level identifies the major external entities, data transformation, data flows, and data stores of the system (Figure 8-5). This diagram shows the relationship between the patient activities and the data that are part of the clinical activity of a visit. The data components is coded with a “D,” and the process components are coded with a “P.” Each major data and process component is numbered. This process begins with the patient making an appointment and follows the process through registration, clinical service provision, collection and processing of the data needed to bill for service, the review and analysis of patient information, and updating of the patient’s problems, allergies, and immunizations. To understand the system fully, it is necessary to break down the process successively into more detailed parts. This is accomplished through explosion diagrams. Information contained in the hierarchy chart can be used to help construct the successive DFD explosions. Why should an HIM professional possess the skills to construct DFDs? Like the hierarchy chart, DFDs should be developed whether the system is to be developed in house or purchased from a vendor. An important aspect of HIM is the design of information systems to support organizational functions and strategic objectives. To design or redesign systems, processes must be systematically described at the level of detail provided by tools such as the DFD. The construction of DFDs provides an avenue to describe the following:




Without this level of detail, an information system cannot be adequately designed or redesigned.


HIM professionals must be able to interact with users and assist them in systematically breaking down complex systems into smaller and smaller components. They frequently serve as intermediaries between users and system developers. The processes represented in DFDs are much easier for users and developers to understand than if the processes were described in narrative or prose form. DFDs often help to resolve discrepancies in perceptions of how something is done or should be performed. Using DFDs helps to avoid confusion, which is a critical element in any system design process.


image


Data dictionary


The data dictionary describes all the primitive-level data structures and data elements within a system. It is the central repository for all information about the database and functions as a catalog for identifying the nature of all the data in a system. It provides the central resource for ensuring that standard definitions for data elements and data structures are used throughout the system. If you are blending data systems developed over time or by different organizations or vendors, the process of harmonizing the data dictionary is critical. For example, the terminology used for data elements may vary. The same data element may be called something different in each vendor system (i.e., patient number, billing number, medical record number, sequence number. The typical data dictionary includes information about processes, data flows, data stores, and data elements in a system. For example, in a data dictionary, the data element “gender” used in a master patient index would contain information about the data element’s data type, its length, its range, allowed values, and meanings. In this case, the data element “gender” has a data type of alphanumerical, its length would be one character, and allowed values would be “F,” “M,” “O,” and “U.” The meaning would be included as a notation indicating that “gender” referred to the patient’s gender and that “M” meant male and “F” female, “O” meant other. It would also be possible to add the category of Unknown, “U,” if this information is not always available. Work has also been done to expand gender categories, and if your organization needs to track a larger set of values, those can be found in standard tables (Figure 8-6). Additional discussion on data dictionaries can be found in other chapters.



How is the data dictionary compiled? There are several ways in which a data dictionary can be notated.3,8 The style used depends largely on the procedures established and the preference of individual information system departments. There is usually a unique notation for data structures, data processes, data flows, data stores, and data elements (Figure 8-7). The label is daily discharge list. The entry type is data flow. The description gives a more complete explanation of the data flow. There is no alias. Note that in this data dictionary entry, there is no “values/meaning” section. In its place is an area for noting the composition of the flow. In this case, the daily discharge list is composed of current date, medical record number, patient last and first names and middle initial, patient’s date of birth, admission date, and discharge date. The location of the data flow is indicated in the last entry of this notation. This list can be generated from the hospital’s Reg/ADT system and stored as a report or printed as needed. A primary user of this report is the HIM department.


Related posts:

  1. 9. Managing electronic health record systems: collaboration and implementation
  2. 1. Health care systems
  3. 12. Performance management and patient safety
  4. 10. Statistics and data presentation

Stay updated, free articles. Join our Telegram channel
Tags:
Mar 15, 2017 | Posted by in NURSING | Comments Off on 8. Information systems life cycle and project management

Full access? Get Clinical Tree
Get Clinical Tree app for offline access