chapter 8 information systems lifecycle and project management

91 terms by Patsyh1969 

Ready to study?
Start with Flashcards

Create a new folder

Advertisement Upgrade to remove ads

chapter contents

information system analysis phases

the health information managers 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, information systems.

To assist in accomplishing the goal of choosing and maintaining the best systems, the information system process usually consists of six principle phases:

1. Initiation phase
2. Analysis phase
3. Design phase
4. Implementation phase
5. Operations/maturity phase
6. Evaluation phase
taken as a whole, these phases make up what is typically called the information system life cycle.

Initiation phase

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. It supports an integrated approach to acquiring new products and ensures a clear identification of the project scope as a starting point. Goals are:
a budget
a schedule
identification of system integration requirements
statement of the problem as understood at this point are outlined

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 the user tasks. 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. 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, play and processes, in the associated functional requirements so that appropriate decisions can be made.

Design phase

on the basis of the findings or requirements that are identified in the analysis phase in on a design 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.

Implementation phase

involves making the system operational in the organization - implementation characteristically covers a wide range of tasks including the following:
system testing
user training and retraining
site preparation
managing organization change and system impact

operations/maturity phase

as the use of information systems increases in healthcare facilities, personnel (clinical and administrative) who use the systems grow dependent on them to do their jobs. These systems need to be reliable and available, often 24/7. Tom Payne, M.D., noted that causes for systems outages at the University of Washington clinical areas have been highly variable, including construction mishaps serving cables, the air-conditioning system failures, users mistakenly plugging two ends of a network cable into adjacent wall ports, and denial of service attacks.

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. Foregoing the evaluation stage may mean that potential system benefits are not realized - to achieve maximum benefits relaxation, all systems should be evaluated against predeveloped criteria and needs requirements.

the players

subject matter or domain expert: provides information on what is actually happening or what should happen in the information needed in the process or product under development.
Functional or business analyst: captures the information from the subject matter experts, organizes that, 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.
Developmental 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 (for example, 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.

role of the health information management professional

should be an advocate for use of appropriate strategies and tools that help ensure the development or selection of information systems that needs organizational needs. The health information manager usually cheers or serves on several information related organization and department committees:
committees charged with enterprise wide information management
information privacy
information security
EHR systems
templates and forms
decision support systems
strategic planning for IT
departmental IT
as an advocate for effective system development or selection, I health information manager and key HIM specialists should assume a prominent role in the system development life cycle.

project management

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.
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.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. 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. This 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 flowcharts and visuals to help track the deliverables and progress of the project.

Monitoring and control

is a 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 the deliverables are on time and within budget.

System Life Cycles

Four perspectives:
1.General system life cycle
2.Information system life cycle
3.Discontinuity of information system life cycle
4.Organization-wide information system life cycle

General System Life Cycle

information systems are similar to biological, social, and political systems.
Four phases
Birth and development (Phase 1)
Growth (Phase 2)
Maturity (Phase 3)
Decline (Phase 4)

Information System Life Cycle

Information system life cycle phases:
Design- is the phase in which analysis of the requirements and design of the information system occurs.
Implementation- is the development, testing, and implementation.
Operation and maintenance- is the activity of the information system lifecycle which is similar to the maturity phase of the general system lifecycle. This is the functioning phase of the system in which activities maintain, update, and operate the system.
Obsolescence- deterioration or decline

Timing of each phase varies from system to system.

Information System Life Cycle in the Organization

Organizations composed of hundreds of interacting information systems
Multiple information systems in different phases of information system life cycle
Important for health information managers to recognize this variability
Different systems competing for different resources
all these systems use some type of IT to assist them in carrying out their functions.

Aggregate Information System Life Cycle of the Organization

Organization as a whole has a life cycle of its own.
Organization-wide information system process stages:
Initiation - organization begins to automate information functions
Expansion - growth of information automation; usually unplanned
Control - organization tries to manage IT growth and resources
Integration - organization attempts to apply organizational standards, policies, procedures
Data administration - integrated databases are developed
Maturity - growth of applications focused on strategic importance
Identifying an organization's point in the life cycle helps explain the existence of certain policies and strategic decisions.

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.

INFORMATION SYSTEM LIFE CYCLE

Eight principles to use with systems approach and technologies:
1.Get the owners and users involved.
2.Use a problem-solving approach.
3.Establish phases and activities.
4.Establish standards (documentation, quality, automated tools, IT).
5.Justify systems as capital expenses.
6.Do not be afraid to cancel or revise scope (reevaluate cost-effectiveness, feasibility, scope).
7.Divide and conquer (subsystems can be built into larger systems).
8.Design systems for growth and change.
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. This is the time to set out project scope and objectives accompanied by a narrative to give context.

Problem Analysis Basics

Apply business process redesign first to address and solve problems.
Then identify where the application of automation makes sense.
Architectural layers of software:
Presentation layer - user interaction (tip of the iceberg)
Business logic layer - business logic rules
Data access layer - storage, access, navigation, data tables

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. The focus in the design area is more conceptual and 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.

ANALYSIS

Development or selection of information systems can be a difficult, arduous process.
Goal of analysis
Build on initial work
Determine feasibility
Confirm scope

Analysis will confirm or determine the following:
Whether there is a need for a new system
Whether the organization can afford a new system
Whether the organization has sufficient technical expertise to develop or operate the new system
What general functionality is expected
What benefits are expected from system implementation
the beginning of any development project effort usually starts with a perceived need or an effort to solve a problem. 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 lifecycle. The launching of the development process may also be initiated by users who believe that new technology is required to support their daily tasks.
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.

Tools and Aids for System Analysis

Several tools used in systems analysis include:
Action diagrams
Context diagram (communication)
Data analysis diagrams
Decomposition diagrams
Data flow diagram/process model
Data mapping and models
Decision trees and tables
Entity-relationship diagrams
Use case-scenario

Decomposition Diagrams—Hierarchy Chart
Hierarchy Chart(is a type of the decomposition diagram) - breaks down problems into smaller and smaller detail
Identifies all tasks in a process and groups them into various hierarchical levels
Organized in a treelike manner
Forces a review of the current process
Can provide foundation for building data flow diagrams

to construct a hierarchy chart

list all tasks in the order in which they occur
to develop a tree structure, it is necessary to assemble the process together in functionally similar groups. Why would an H I am 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 process of developing the chart forces a review of the current process. Redundancies in work patterns can be identified and inefficiencies can be corrected.
The hierarchy chart can provide the foundation for building data flow diagrams.
The chart provides a means to communicate with developers and can also be used to access whether a vendor product will meet user needs.

Data Flow Diagrams (DFD)/Process Modeling

Specific symbols used to identify each DFD component
Moves from complex to simple
Context level identifies major components
DFDs provide an avenue to describe the following:
Where data originate
How data are transformed
How data flow
Where data are deposited

the DFD answers the question, "now that the basic processes are defined, what data is needed for the processes to be carried out?) DFD's identify the data flow within a system, and Athens 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 DFD's:
external entities- includes people or groups of people who interact with the system but are not internal to it.
processes- our actions performed on data.
data stores- Data stores are repositories for data - they may be either temporary or permanent storage areas.
data flows- represents the movement of data through a system - data move out of entities, to entities, between processes, and into and out of data stores.

data dictionary

Describes all primitive-level data structures and data elements within a system
Central repository for all information about the database
Functions as a catalog for identifying the nature of all the data in a system
Central resource for ensuring the use of standard definitions for data elements and data structures

How is the data dictionary compiled?
Style used depends largely on the procedures established
Information system department preference
Usually a unique notation for each component

Visible Analyst Workbench
Project - name of the related project
Label - unique data name
Entry type - type of data entity
Description - used for more complete description of data entity
Alias - Other names by which the data entity is identified
Values and meanings - Notation depends on the data entity type

Why is the development of a data dictionary important?
It provides a central repository of standard terminology.
It helps reduce data redundancy.
It increases data integrity.
It helps to fully document information system.
It helps to decrease confusion among users and analysts about purpose and functions of system.

the typical data dictionary includes information about processes, data flows, data stores, and data elements and a system. For example, in a data dictionary, the data element gender used in a master patient index would contain information about the data elements data type, its length, its range, allowed values, and meanings. In this case, the data element gender has a data type of alphanumeric, its length would be one character, and allowed value 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 am meant male and asked female, oh meant other. It would also be possible to add the category of unknown, U.

How is data dictionary compiled?

There are several ways in which a data dictionary can be notated. The style used depends largely on the procedures established in 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. The label is daily discharge last. 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 last is composed of current date, medical record number, patient last and first names in middle initial, patient's data 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 hospitals REG/ADTsystem and stored as a report or printed as needed. A primary user of this report is the HIM Department.

data mapping

data mapping and the data dictionary have relevance to one another in that the data dictionary may carry alias terms that help systems recognize that a term has several synonyms. Example - one system may call an individual a patient and another system may call the individual a client and another system may use the term resident.

Legacy system is an older existing system that may need to be interfaced into new system, or continue unique function, or be shut down.
Some or all of the data may need to be mapped to new system.

Entity-Relationship Diagrams (ERD)

Used principally to illustrate the logical design of information system databases
Composed of three categories of items:
1.Entities - objects that make up the data in database
2.Relations - links or ties that exist between or among entities
3.Attributes - describe both entities and relations

Why is the ERD important?
ERD is an important tool for development of a logical data model of system.
Poorly designed logical structures cause inefficient and ineffective databases.

an example of a relation in the record completeness review system is the relation between a patient record (and entity) and a deficiency (and entity). In this relation, a patient directed can have many deficiencies (for example, there may be several physicians, each having a deficiency, or the wreckage may have several content or signature deficiencies). Another example is the relation between a physician (entity) and a record content/signature deficiency (entity). In this relation, a physician can have many content/signature deficiencies in a number of patient records (for example, have deficiencies for more than one record) to say.

Attributes describe both entities and relations - attributes may be thought of as the data elements that need to be captured to describe an entity fully. An example the attributes of the deficiency card in the manual record completeness review system include patient number, physician name, position number, and list of deficiencies. The attributes of the entity (physician) would include physician number and physician name.

In an ERD, entity and relation symbols are connected by straight lines. In addition to indicating a relation among entities, it is important to indicate how many frequently the occurrence can exist at any given point in time. Each patient directed can have more than one (or many) data deficiencies the reverse of this is that each data deficiency can relate to only one patient record.

In an EHR system, the record deficiency data are posted as a "to do" list for the care provider and tracked by the HIM professional.

computer aided systems engineering tools

a logical question that should arise after studying the various structured analysis tool is, "how are the products that are derived from each of these tools integrated?" In other words, how other charts, diagrams, dictionaries, and tables tied together to derive a coherent picture of system design? These development tools a computerized to improve the efficiency, accuracy, and completeness of the system development process. These computerized systems are called computer aided software engineering (also referred to as computer aided system engineering), or CASE, tools.

CASE toolsprovide a mechanism for the electronic development of systems analysis aids such as structure charts, DFD's, ERD's, and data dictionaries. Instead of developing charts and diagrams manually, the analysts can use a computer program with a graphic interface to assist in development. CASE tools do not automatically develop the various charts and diagrams. Rather, the designer interacts with the CAFC program to select the appropriate symbols, connectors, and labels and electronically draw the proper diagram. All diagrams, graphs, tables, and dictionaries that are developed are stored electronically.

CASE toolshelp design is relate their work electronically by organizing information about a system in a central repository. The central repository may contain data models, logic definitions, and functional models and may screen and report definitions. After it is developed, designers can query the repository for information about the system.

if new processes are added - models, graphs, tables, and dictionaries can be reused or easily updated.

Advantages of using computer aided systems engineering products

there are many benefits to using a CASE product. An obvious benefit is convenience for system designers. CASE products provide an effective mechanism for development, storage, retrieval, and update of charts, tables, diagrams, and dictionaries. Updates, enhancements, corrections, or extensions to already developed charts and diagrams can be easily accomplished with use of CASE products. CASE allows faster development of analysis tools. Data models can be efficiently developed and results shared with other design team members and users in a timely or manner than by using manual methods. Reduction of areas is another benefit of using CASE products in the design process. Because CASE products and force organizations of system details and contain automatic consistency checks, areas and design are reduced. CASE products also increase coordination within and among projects, resulting in better standardized nation. Standardized nation leads to better system documentation, which can easily beam maintained and updated.

disadvantages of using computer aided systems engineering products

although many advantages can be realized by using CASE products, some disadvantages also exist. CASE products can be expensive - training costs for updating this skills of designers and analysts must also be considered. Because one vendor does not usually provide an entire set of tools that are required to develop an information system, products from several vendors may have to be purchased. The use of several vendor products can increase costs and training time and can create problems with integration.

investigative strategies for analysis of requirements

the importance of developing structured tools such as hierarchy charts, DFDs, and data dictionaries when describing a system - these tools require the gathering did. Interviews with users, questionnaires, focus groups, observation of tasks, and review of documents, forms, and procedures - is essential to successful systems design - because H I am professionals often serve as liaisons between system developers and the end-user community it is important that they understand and become skilled in the techniques for gathering information.

Interviews

are a common method for gathering information about system requirements. Advantages:
provides an opportunity for adding users to participate and contribute to the design and development or upgrade of a system.
The interview process helps to break down barriers of user resistance by allowing the user to assume a vested interest in the process
if users are involved in the development, design, selection, and upgrade of an information system they are less likely to resist using the system, thus the system will more likely meet users needs.
Following factors can contribute to a successful interview process:
defining the target audience
identifying the objectives of the interview
developing appropriate interview questions and format
adequately analyzing and documenting responses

target audience

people which are most familiar with system requirements on operational and strategic levels. The interview process might also include physicians, nurses, and other caregivers working with outpatient areas because certain disclosure of information is most likely occurring in these areas as well.

Interview protocol

should be developed and field tested before the interview process is implemented. A structured questions allow more probing of end-users then do structured questions.

Scenarios/use cases

can also be used in the interview process - the end user is presented with a scenario or a use case that represents an actual situation. The scenario or use case centered interview is popular - is that the end-user can respond to questions in the context of real environments.

Field testing is advantageous for a number of reasons

it allows the interview questions to be tried out on a sample group (clarity, appropriateness, and completeness of the interview questions can be assessed during the field test process)

allows the analysts to determine how much time must be scheduled for interviews during actual interview process

the field test gives the interviewers an opportunity to develop their interview skills and hone the interview process - more skilled the interviewer, the better the results from the interview

documentation

format for the interview documentation usually includes:
interview date
name and position of interviewee
names of interviewers
list of questions pose
responses to questions
synopsis of the interview

overall analysis and synthesis

includes:
description of the method
list of all interview questions
list of all end-users who were interviewed
synopsis of all facts and opinions
general synthesis of interview material with recommendations

questionnaires

are a popular method for gathering data - less time-consuming - less costly - can be distributed to large target audience.

Can be severely diminished for several reasons:
they are frequently ambiguous
poorly constructed
too long and have low response rates

questionnaires should be structured allowing yes or no answers or multiple-choice options

question construction

only questions pertinent to the purpose of the survey should be included - questions are only as good as the degree to which they measure what they are intended to measure - clearly identified - list of measures that are anticipated

questionnaire construction

having a set of good questions is the foundation for building a questionnaire - a poorly constructed questionnaire even if it contains good questions can yield a poor response rate
a good questionnaire:
choose a concise suitable title for the survey document
clearly state the purpose of the survey followed by simple easy-to-follow directions
order the questions in a logical sequence

questionnaire administration

a cover letter to the end-user should accompany the questionnaire - cover letter is the vehicle for getting the end user excited about the survey - state purpose - what value the results will have - how the results will be used - assured responses will be kept confidential

Observation

is an appropriate technique for collection of information about system requirements or identifying tasks performed by end users - is usually used as an adjunct to interview and questionnaire techniques - results of observation can be used to confirm or expand on information collected

observation should not be distracting to users

document and form review

review of forms can identify which data elements of facility routinely collects - can also help to determine information flow by identifying form or rejuvenation, distribution, and archival locations - healthcare facilities a notorious for the number of forms they used to collect data

group analysis and design

is often used in a place of other traditional structured approaches to data gathering - often referred to as joint application design (JAD) or joint requirements planning (JRP). - Is a group of people spending a concentrated time together in determining system requirements. Usually composed of end-users, managers, analysts, and others who may have an impact on or be affected by the system under study.

Group decision support software (GDSS)

used to facilitate the JAD process - products typically include word processing and text and database manipulation - other functions such as electronic worksheets, graphics, and communication capabilities are customarily included.
Benefits:
use of JAD stimulates interaction between end users and analysis in a positive, nonthreatening environments
facilitates the development of unbiased results through the use of structured processes such as brainstorming, Delphi, nominal group technique, and group consensus techniques.
Gives everyone the opportunity to meet and have informal discussions
the use of JAD usually produces results in shorter time frame than other investigative techniques.

System design

encompasses activities related to specifying the details of a new system - needs and requirements of a system - translated into specific needs to build the system - decisions about the logical and physical designs of the system are made

logical and physical designs

logical design describes the functionality of the system and is sometimes called the functional specifications of the system - vision of system performance and its features
stair - provides a traditional list of logical design outputs as follows:
output design - specifications, format, contents, frequency, screens, reports for output data.
Input design - format, contents, frequency, for input data.
processing design - data manipulations required, calculations, comparisons, and text manipulations.
File and database design - capabilities/real-time update of patient file or record.
Controls and security design - specifications for data access and backup - another method of describing system functionality is to use scenario-based format - could alleviate the problem presented - good mechanism for describing system functional requirements

the physical system design section specifies all the characteristics that are necessary so that the logical design can be implemented - the physical design includes details about the design of hardware, software, databases, communications, and procedures and controls.

Design principles

among other physical design characteristics are program accuracy, augmentability, completeness, consistency, efficiency, maintainability, reliability, and reusability.
H I am professional is commonly not involved in assessing these technical design characteristics
system functionality usually involves three things:
input
output
system performance

input and output

goals of input process:
to make entry of data into an information system easy so that transactions can be quickly and accurately completed.
To integrate the process to such a degree in the employee workflow that it is transparent to the end-user - the input mechanism is on obstructive.
To reduce duplication and work effort while ensuring a better quality product.

Goals of output process:
to assist the end-user and retrieving appropriate data at the appropriate time in the appropriate format.
To provide information that is accurate, timely, complete, and specific to the query.

Screen design

an important part of input and output - many options are available to navigate and display elements of a complex software package such as an EHR.
Dialog boxes are special application of a window - is to elicit a response from the user
icons are graphic representations of real-world objects that help convey the user the purpose of a command
caller is an option that is often used in interface and screen display design - color should be used conservatively, principally to enhance the identification of important data or draw the users attention to important functions.

General design characteristics

a primary virtue of an interface is its degree of simplicity - system should be able to perform:
respond quickly to user commands
provide a useful and simple messages
offer good navigation tools
provide adequate power to perform necessary tasks

another important part of an interface is the input device - input mechanisms are keyboard, mouse, light pen, touch sensitive screen, voice-recognition, pen-based system, handheld device, barcode reader, smart phone, and laser scanning.

System performance

system performance issues must be considered - from end-user perspective, functional system performance indicators may include such criteria as degree of data accuracy, system response rates, system efficiency, system security, and ease of system use

role of prototyping in system development

prototyping a system usually has the following primary goals: to build the Prototype of an information system quickly
to involve the user heavily in the model development - initially the system Prototype can be a preliminary model of the final system, but after several iterations of development, the Prototype can evolve into the final system - it is not usually done at the depth required in the system development life cycle.
after input and output prototyping is completed system features are gradually added (most important functions of a system are typically incorporated first)
final stage of prototyping is generation of the completed prototype system - Prototype is tested and evaluated and if changes to the Prototype need to be made this system is updated and evaluated again.

Prototype and is gaining popularity for a number of reasons:
provides immediate feedback to uses in a format that has meaning to them - users assume responsibility for approval of design and function capabilities
Prototype skin stimulates the dynamics of the real world (it is difficult in a DFT to access the stress and cured by an emergency department physician in the urgency as she or he attempts to locate information about a drug regimen and a patient's file)
a final benefit provided by Prototype thing is faster delivery of products than that provided by the traditional method of systems analysis
several other factors have contributed to the increased use of Prototype method:
advances in technology have made Prototype impossible
there has been growth in prototyping tools
users have access to and experience with relational databases on their computers and may be able to do some initial design/use work to speed the formal process

some critics believe that in the haste to develop a product quickly, insufficient effort may be devoted to the analyst process - prototyping however can be integrated into the system development life cycle.

System implementation

usually refers to all the tasks associated with getting the information system installed in operating - implementation should occur as soon as feasible after the initial decision is made to go forward on the design or selection of a system. The key to a smooth implementation process is planning and well executed management.
Implementation process:
user preparation and training
site preparation
system on module testing
system conversion on module edition
system are module start up

user preparation and training

are probably among the most underestimated tasks in the implementation process - users need both to be trained in how to use the system and educated about the system's purpose, benefits, and how it supports the overall well-being of the organization.
Curriculum content should begin with easy concepts and operations. The presentation method of the curriculum must match the knowledge, skills, and availability of the end-users. Self-paced training modules is an alternative to holding large classroom style classes. Scheduling of training sessions can be an anonymous undertaking. Another component of any user preparation is the selection and training of the trainers.

Site preparation

location of system and its associated components need to be planned well in advance of installation - any oversight can turn any installation process into a nightmare.

System testing and conversion

must be tested to ensure that they perform in the way intended - good system testing is a precursor to successful installation - can be tedious process.

test phases

used to test systematically the performance of software

system conversion

technical issues to be addressed during any conversion can be complex - quality control procedures in place that ensure the integrity of data and transactions - HIM professional should be a part of the team for quality control during the conversion process.

Start up

occurs when all activities leading up to installation have been completed includes user training, site preparation, hardware installation, testing, and conversion - approaches to start up phase:
abrupt changeover
gradual phase in applications is selected organizational units
gradual phase in of applications organization wide

abrupt changeover

refers to total rollout of a system across all organizational units at the same time- exceedingly risky (unless system is simple)

gradual phase in of applications

refers to bringing up one application at a time and selected units over a period of time - this approach is risk adverse - debugging any problems that occur is easier because each application is tested and debugged as it is implemented.

System evaluation and benefits realization

should start in parallel with the system design effort - purpose of system evaluation is to determine whether the system functions in the way intended - method used to evaluate systems:
benefits realization
cost-benefit analysis
cost effectiveness analysis

benefits realization

criteria used for system evaluation evolved from the analysis and design sections of the system's life cycle - goals of this system are as follows:
decrease response time to requests for information
easily track pending requests and due dates and reasons for pending requests (including requests for amendments to a health racquet)
accurately document each release of information
accurately document the name of the staff members responsible for the release of the information
accurately measure the productivity of each staff member responsible for release of information
accurately document what is being released, when, why, how, and to whom
identified those releases made with patient or guardian consent
identify those releases required by law and not requiring patient consent
identify and track performance on those releases for which local law may require notification of the patient to allow the patient to object to a mandatory release (Subpoena) and the outcome
identified discretionary releases(where the laws are permissive)
identify the requests for information that word denied or not and said and the reason
reduce errors in the release of information to external entities
reduce employee time in documenting the release of information data elements
provide for reporting capability (releases of information made without the patient's consent)
calculate daily, weekly, and monthly work volumes
provide for retention of the database for a period of at least six years

cost-benefit analysis

is not usually economics-based, although the potential costs and appropriate release of information could be discussed - system benefits are not necessarily compared with an economic outcome. Cost-benefit analysis (CBA) attempts to measure benefits compared with system costs - the goal of this CBA is to determine whether the information system decreases or increases benefits and whether a decreases or increases cost for the organization.

The term cost-benefit analysis is used somewhat loosely in the information systems field as opposed to its use by economists - uses microeconomic models to assist in making good decisions - dollar values are assigned to the cost and benefits of a proposed information system - dollar values are then compared to help make a decision between alternative systems.

Break even analysis

is probably the most simplest CBA technique - cost to operate the current system are compared with those to operate the proposed system.

Payback period

is often done to determine whether a new system will fully recover its investment/development cost before the end of its life cycle.

discounted payback.

An organization determines how much a system costs in future dollars - basic concept underlying this approach is that today's dollars are worth more than future dollars - this is because an organization can usually invest today's dollars at a certain interest rate and receive a return on investment (ROI).

To determine the present value of today's dollar at any time in the future the following formula is used:
1/(1 + ROI)n

cost-effectiveness analysis

attempts to evaluate certain beneficial consequences in nonmonetary terms - desirable benefits are not valued in monetary (dollar) terms but are measured in some other unit.

Other evaluation methods and techniques

in addition to the three previously discussed the valuation methods (benefits realization, cost-benefit analysis, and cost-effectiveness analysis)
evaluation of computer systems/system is being used as it was intended/choose research method/quality of research attempts to answer questions about how and why specific outcomes occur (this type of research is particularly useful in studying the design, use, and implementation of healthcare information systems) (drawback of quality of research technique is that it relies on the observation and interpretation of one or few evaluators - may introduce bias into the evaluation results - role of quality of research is increasing insignificance to answer questions that quantitative measurement does not answer) survey methods are frequently used to study the outcomes of healthcare information systems. Experimental research methods can also be used to evaluate various aspects of information system implementation - methods demand a much more rigorous environment and require the use of control groups.

Purchase and process requests for proposal

a request for proposal (RFP) is a document that details all required system functionality, including functional, technical, training, and implementation requirements - document is distributed to a selected number of vendors who are invited to respond to the proposal.

Request for information

request for information (RFI) is generally known at this point about system capabilities so that an intelligent decision can be made about which vendor products are most likely to be competitive in a response to an RFP - RFI basically solicits general information from vendors about their product.

Planning steps before request for proposal preparation

membership of the committee is commonly multidisciplinary, including users, managers, and representatives from administration and information systems - broadly encompass the following:
development of project work plan and timetable
oversight of systems analysis
development of system specifications
determination of costs and benefits
compilation and distribution of the RFP
evaluation of responses to the RFP
selection of the system
conducting vendor negotiations
oversight of system implementation

analyzing system requirements

this process of identifying user requirements and determining system capabilities is essentially the same as in the system life cycle - steering committee may assign members of the committee analysis responsibilities to delegate these two in-house information system professionals.

Development of system specifications

include both the functional in the technical specifications of the system - logical and physical descriptions of the system - related to output, input, processing, database, and security design.

Development and distribution of the request for proposal

usually a lengthy document - can have several hundred pages - usually includes:
proposal information and format
enterprise profile
conditions of response
functional requirements
technical requirements
training requirements
implementation requirements
vendor profile
system costs
in RFP is a professionally prepared document - accuracy of the RFP cannot be over emphasized.

Disclaimer and table of contents

RFP usually begins with a disclaimer/proprietary and is considered to be strict confidence - a table of contents that functions as an index to the RFP.

Proposal overview

an overview of the proposal is usually presented

enterprise profile

a profile of the enterprise - brief description of the organization and its demographic data (statistics such as bed size, occupancy rate, and number of admissions, discharges, procedures, and outpatient visits are frequently provided).

Conditions of response

contains information about what format should be used - the date and time the response is to be submitted - detailed instructions for completing each section - the name and telephone number of the person to contact with questions.

Functional specifications

allows the vendor to indicate whether the feature is currently developed and operational - can be custom developed - is plans to be developed - or is not available.

Installation and training requirements

vendors are requested to submit their installation work plans/length of installation, customer responsibility, and skill level of installation personnel are described - training requirements are also outlined in this section.

Vendor profile

is extremely important to ascertain the stability of the vendor - to minimize risk to the client a thorough background analysis of the vendor should be done.

System cost and financing arrangements

a system class schedule should be prepared for both lease and purchase options

contractual information, references, and other materials

a sample copy of all contracts and addenda that are required for the facility to contract for the proposed system - RFP/facility reserves the right to negotiate the final terms and conditions - references for facilities that are using vendor's products should be requested - vendor should ask to supply a list of all installations of their product

distribution of the request for proposal

before distribution a shortlist of vendors who probably have systems that will meet functionality specifications is identified ash list is usually compiled for information received during the RFI process - remember that for every RFP that is sent a potential response is possible.

Evaluation criteria

the steering committee develops evaluation criteria for analyzing and comparing vendor responses - the following general categories of evaluation are usually considered:
hardware and software configuration
application functions and features
economic considerations
technical considerations
vendor considerations

demonstrations and site visits

The vendors that come out highest in the evaluation process are invited to present demonstrations of their products- the steering committee usually schedules site visits to observe the vendor product in production mode.

System selection and contract negotiation

when a product has been selected contract negotiations began - the contractor will process is extremely important because it lays down the rules through which the client and vendor are to operate. The following items are usually part of any software contract:
identification of products and services
license Grant
delivery terms
installation
warranties
remedies and liability
acceptance and testing
price and payments
term and termination
support and maintenance
contract is a binding document - software contracts should be negotiated by a team of people who have expertise in both legal and technical arenas.

Please allow access to your computer’s microphone to use Voice Recording.

Having trouble? Click here for help.

We can’t access your microphone!

Click the icon above to update your browser permissions above and try again

Example:

Reload the page to try again!

Reload

Press Cmd-0 to reset your zoom

Press Ctrl-0 to reset your zoom

It looks like your browser might be zoomed in or out. Your browser needs to be zoomed to a normal size to record audio.

Please upgrade Flash or install Chrome
to use Voice Recording.

For more help, see our troubleshooting page.

Your microphone is muted

For help fixing this issue, see this FAQ.

Star this term

You can study starred terms together

NEW! Voice Recording

Create Set