Health Care Information Systems

Module 13:Application Development and Project Management

The following objectives should be met by the end of this module:

1. Evaluate options for system design and acquisition
2. Be familiar with criteria used in evaluating commercial software packages.
3. Describe all elements of a system design specification
4. Compare and contrast a RFI and a RFP
5. List and define steps needed for evaluating contract services
6. Understand and be able to describe important elements to a finalized contract for vendor services and support
7. Discuss the role of a IS consultant in the development process
8. Describe and discuss critical success factors for IS implementation
9. Diagram and understand steps involved in successful development and implementation of a new information systems in a health service organization

These notes are intended only to supplement your readings. The best way to ensure each module is absorbed is to complete all the readings prior to reviewing these lecture notes. I will try to highlight what I believe to be the most important topics from your module readings. If you have any questions or concerns or there is something you do not understand, please ask me. You can either post on the webboard the question you have (that way others can benefit from the response), or you can e-mail me if you want a more private response. Either way it is extremely important that you have a complete and thorough understanding of the material for the module.

System design is "the process of converting IS requirements into a detailed set of specifications for a system." At this point, the tasks involved become more technical and additional support may be needed for these functions. The end-users and in-house staff should continue to be used as a "sounding board" for the design that is being developed. This is important because this is the source of requirements for the design, they also have a feel for what the finished project should look like.

System design specifications should include the following elements:

• Statement of System Objectives
• Output Specifications
• Input Specifications
• Database Specifications
• Procedures and Data Flow
• Cost-Benefit Estimates
• Management Approval

If the organization chooses to use pre-designed software for their applications, specific functional requirements are needed. These should be as detailed as possible and categorized as mandatory or desirable. Other areas that may be needed are: hardware and software specifications (if you are using existing IS equipment) and possible interfaces needed for integration with other systems. This "statement of functional requirements" should be used as a tool for analyzing possible software and hardware available. It will help to analyze how closely each package meets the needs of the organization and the users. Any possible selection should be thoroughly checked for past and current users' recommendations, compatibility with current system, and interfaces needed. Further package software evaluation criteria is found on page 221 in figure 9.3.

A detailed cost analysis is a very important step in the purchase of any type of IT. This equipment is expensive and must be justified for the capital it will consume. Costs will fall into three categories:

• The cost (or lease) of the software itself
• The cost of implementation
• The cost of maintenance and updates

All three categories must be included when evaluating and comparing costs between vendors. If in-house development or purchase or pre-packaged software is not the design approach selected, the alternative is to outsource the service. In other words, hire an outside contractor to perform the service.

A Request for Information (RFI) is an informal process generally used when trying to acquire smaller systems. It is a tool to help in the selection of the vendor when deciding to purchase equipment and/or services. With an RFI there is limited documentation required and it is only used to obtain general product information and pre-screen vendors. It should include only a general description of the product the organization seeks to acquire and then asks the vendor to respond. The vendor is asked to provide general information regarding their product and how they would meet the requirements put forth by the RFI. The RFI is used only as a screening tool and those vendors selected from an RFI would be asked for additional information.

A more formal vendor selection method is the "Request for Proposal" (RFP). This process involves more documentation, time and resources. The RFP should provide functional requirements for the proposed system and state guidelines for bidders to follow in their proposals. Evaluation criteria should be decided upon prior to distribution of the RFP's. After all proposals have been accepted the criteria should then be evaluated. After the finalist has been selected, contract negotiations begin. The main elements to be included in an RFP are:

• a formal introduction to the organization
• a statement of functional requirements listed as either mandatory or desirable in priority order
• specification of content and format to be followed in proposals that are submitted
• a statement of criteria to be used in evaluating proposals
• requirements for on-site demonstrations and testing
• general contractual requirements

RFP's have been discouraged in some areas of healthcare because they are too time intensive. The rapid pace of healthcare change encourages speedy development and implementation of systems. They must also be continuously updated to ensure current guidelines are met. One alternative to the RFP is the an abbreviated request, one example is the " Roper Process".

A vendor profile is also encouraged for all potential vendors to ensure that the company is viable. They should be in business long enough to install your purchase and provide services for implementation, training and maintenance. This seems like it should be logical, but in the IT business (especially in healthcare) these companies may be very short term.

Once the vendor has been selected and approved by the IS development team, contract negotiations must take place. The organization is responsible for the negotiations and should proceed with vendors of first and second choice. This will provide an alternative if negotiations are not successful with the vendor of first choice. Legal counsel should be consulted for all contract negotiations. There are legal consultants who now specialize in contracts involving computerized technology. This may be beneficial especially if there is no one in house with this type of knowledge. The final contract agreed upon should put the vendor at financial risk if they fail to meet requirements specified in the RFP. A fixed price and time of completion should be agreed upon in the contract.

The success of the developmental life cycle for IS is dependent upon the success of the implementation. Even if all steps in development are followed, the system will not be successful if the implementation is done improperly. Factors must be identified in the organization that will define system success. Once these have been determined, an implementation plan can be developed. This process involves addressing guidelines and standards for the new system, any legal and ethical issues, a listing of implementation steps and activities needed. The plan can then be distributed for review prior to beginning implementation.

Critical success factors to implementation fall into three categories. Each of these categories must be carefully analyzed to determine how to succeed in each area.

User characteristics are by far the most important for success of any IS implementation. Users who are not well trained or do not have correct expectations of the system will be disappointed with the final product. It is important to emphasize and promote the system only as a tool rather than a solution by which to solve their problems. The goal of any IS system should be stressed as only a means to support decision making and problem solving activities. If the new system is thought of as the "savior" to all the organization's problem, there is bound to be disappointment once the system is up and running. User resistance to a new system is the most destructive behavior related to implementation and can quickly lead to implementation failure. For example, if all users refuse to learn and use the new system it will not be successful. There are five noted factors that are related to user resistance of new IT. The recognition of these factors can help alleviate resistance.

1. New technology implies a change in department or divisional boundaries. This may create a sense of fear of losing a job or position.
2. IS can impact the informal organizational structure
3. Overall personality of users; (younger, inexperienced users are less likely to resist change than older, more experienced ones)
4. Peer pressure and previous experiences can influence attitudes toward new systems
5. Management techniques in developing and implementing IS can influence users perception of the system

User orientation, training, education, and participation are ways to minimize any user resistance or problems that may follow introduction to a new system.

The following diagram is a schematic representation of a IS implementation. This diagram also includes the life cycle of development for IS we are discussing in this text. All steps must be correctly and meticulously performed using an interdisciplinary team from the organization for success of the system.

Tan, JKH. Health Management Information Systems: Theories, Methods, and Applications. Aspen Publishers, Gaithersburg, Maryland. 1995