14. Breaking the Automated Patient
Medical Record Project Into Phases

14.1 Project Context: Project Plan--Breaking the Project into Subprojects, or “Phases”

A large-scale complex project (such as improvement of patient care through automation of the patient medical record) involves completing many interrelated subprojects or “phases”. The phases for the project are determined in the Project Plan step in the overall analysis phase. See figure 2.10.

From the phases, a project plan for the project is developed by ordering the phases in a network, determining how they overlap in time in their execution. The ordering of phases is dependent both upon technical and managerial considerations, with those phases dealing with infrastructure always being done first--see section 14.4. Each phase could then be treated like a project, being assigned a phase project manager, with the tasks done in detail in each phase, producing a phase project plan. The results of this process are thus an overall project plan scheduling phases, and project plans for each of the phases, each scheduling tasks for the phase.

For tasks and then phases, time, costs, resources, and performance parameters are assigned based upon project constraints from management. Obstacles to the completion of the project (risks) are identified, and contingency plans may be developed for obstacles should they may occur.

At the end of the Project Plan step, the overall project plan and various phase project plans will have been determined in detail, including the costs of each task and each phase; because of this, at the end of the Project Plan step, upper management will have better information on the true costs of the entire project and of each phase than in the Evaluation step where the initial estimation of costs was done and the initial determination to go ahead with the project was done. At this point, upper management can determine again, based upon costs, whether to go ahead with the project or not, and whether to pare down the project.

The success of the project from management’s point of view is that the project meets certain project objectives. Because these objectives are normally not all reached until the end of the project, it is useful to develop goals that lead to the objectives (e.g., 40% of patient charts will be automated by end of the third year.) The project plan can be used to determine the best points in the project to set these goals to measure the progress of the project.

14.2 Project Management

Project management [1] is a systems approach to development and implementation of a defined set of inter-related products with the development and implementation described by a project plan breaking the development and implementation into tasks stated in terms of time, costs, resources, and performance parameters. The end product of the project is a system within the organization, which is one of several inter-related systems within the organization, where each system in the organization supports the others. Resources may include workers, equipment and rooms.

Project management involves a project manager. Through the process of planning, organizing, directing, controlling and monitoring, the project manager coordinates the application of resources to the project with the objective of completing tasks within the project plan, with the final task being the implementation of the project.

For a complex project, the project plan for the overall project would have phases of the project in place of the tasks; there would be an overall project manager. Each phase would have its own project plan with tasks being activities within the phase, and would likely have its own phase project manager.

Both phases and tasks, which can then be scheduled, can be determined by an approach such as a Work Breakdown Structure (WBS). The project can be broken down into phases for the overall project and to tasks for a phase of the project. For example, figure 14.1 illustrates a WBS for the overall automated patient chart system project.

The project plans should include milestones. A milestone is a marker for a major event in the project.

As we noted previously, in particular after each phase and before the next, an evaluation should be done by management to determine if goals are being met, objectives are in the process of being fulfilled, and a decision is made on whether or not to change or continue the project. Such a decision point has also been called a gate [2]. A gate is one of a number of decision points in the project where an evaluation is made to revise or terminate the project. In order to get upper management to commit a significant amount of time at the appropriate time to evaluate the progress of the project, it might be useful to schedule gates in the project plan.

Anticipated project risks should also be considered, along with contingency plans for handling these risks if they indeed occur. One approach is to schedule a task in the schedule to do the contingency plan; this task would start at the time the risk is expected to occur. For example, a risk might be that national standards for the automated patient medical record have not yet been established; a task would be put into the project just before standards are needed to determine if standards exist, initiating a contingency plan if not.

The overall project plan can be viewed as a network of phases. See figure 14.2. Each phase, itself has a project plan, which is a network of tasks. ‘P’ represent a phase, ‘T’ a task, ‘M’ a milestone, ‘G’ a gate, and ‘R’ a risk consideration point. Each task is assigned time to accomplish, costs, personnel and other resources (e.g., equipment) to accomplish, and performance parameters. From these, time, costs and resources for each phase can be determined; from this, the time, costs and resources for the overall project can be determined.

See references [1], [2] and [3] for more on project management.

14.2.1 Gates

See figure 2.3. Initially in the initial Evaluation step and thereafter in Evaluation steps occurring at predetermined points in the project, management will reevaluate the project for adherence to objectives and to determine if the project should be changed or should move forward.

Those decisions made by management in the Evaluation step are referred to as a “gate”. Compare the Evaluation step in figure 2.5 to the decision in figure 14.3.

A large program or project such as the automated patient medical record system program must be evaluated periodically by management for adherence to current company objectives, business strategies and goals, monitored as to ROI and compared to other projects. Gates [2] are decision points where these evaluations occur. This evaluation determines the following (see figure 14.3):

· Can the program/project be simplified or improved?

· Does the program/project still fulfill company objectives, further the goals of the company and implement business strategies?

· Does the current ROI of the program/project justify its costs? Will there still be funding?

· Is it better to implement another project or other projects with higher priority instead?

Termination of the project might be considered if any of three latter questions is “no”.

14.2.2 Risks and Contingency Plans

Risks can be identified at any time during the project. Some risks can only be identified when the occur--see the next chapter. Other risks can be anticipated at this stage, with decision points and contingency plans built into the schedule just before the risk would occur.

For example, a phase may require that an event takes place first (e.g., standardization of medical vocabularies in the healthcare industry). There must be a contingency plan if it doesn’t take place.

Within a project plan, a risk could involve the choice of two phases, with a contingency plan resulting in one phase being done instead of the planned one. See figure 14.4. For example, there may be a phase to replace all HMO clinical systems with a common system for each type of clinical system, with inclusion of HL7 interfaces for each to the automated medical record system(s). Such an approach may prove to be too costly, so a contingency plan might be to substitute a phase simply implementing HL7 interfaces between existing clinical systems and the automated medical record system(s), if the other approach turns out to be too costly for the corporation at the time of the start of the risk determination.

14.3 Determination of Phases for the Automated Patient Medical Record Project

The determination of the phases or sub-projects of a large project and their order is an important and difficult task. The governing principles for breaking the project up into phases are that

· Phases should be small enough to be manageable by a single project manager assigned to the phase, but not so small that the phase project manager does not have control over resources and decisions that determine the success of his phase.

· Every phase of the project must be done with a clear understanding of how the phase fits into the overall project. Phases are developed with an understanding of the logical dependencies between phases, such as this phase must precede another one as it supplies the information needed in the following phase

· Phases that incorporate the overall infrastructure to tie the phases together should be done first (a security system).

· Phases might be determined based upon achieving management goals (e.g., such and such a capability should be completed by such a date, or such and such phase will make money for the corporation and should thus be done first).

In order to start off this process, it is useful to break up the project into logical project categories. Phases might either be defined to be the same as the logical project categories (e.g., develop overall infrastructure for project) or to cross project categories (e.g., develop this subsystem that includes the infrastructure needed by this subsystem). This process can, as stated in section 14.2, be facilitated by a Work Breakdown Structure.

The automated patient medical record project, if initiated by a single HMO, might consist of the following interrelated project categories:

1. Planning and Research—Plan overall project . Perform necessary research areas (see chapter 17) so they could be completed before their scheduled implementations.

2. Infrastructure—Implement hardware and software infrastructure within medical centers. Install wiring, networks, computers, printers and other peripherals, and system software, including operating systems. Infrastructure should generally be installed only as needed, such as hardware and software for diagnostic imaging (PACS) systems. Maintenance personal to support changes and corrections to hardware, to released software and to controlled documentation could also be considered part of the infrastructure, or could alternatively be considered to be a separate project category.

3. Interfaces—Implement interfaces between the subsystems as described in section 13.10. Develop an implementation plan for the HMO, CPR repository, patient registry and source document repository hardware and software infrastructure as necessary to implement the interfaces.

4. System and Subsystem Development -- Design, develop and install the necessary systems and subsystems for the HMO (initial local system, regional system, CPR repository, source document repository, patient registry, virtual local system and clinical research subsystem). Integrate HMO clinical systems with the regional and local systems.

5. System Evolution and Expansion -- Create additional local systems, if applicable. Create additional local and regional systems in other healthcare organizations. Create additional CPR repositories and source document repositories for Patient Health Records for patient outside the HMO.

6. Reengineering the HMO -- Workflows of caregivers must be redefined radically or at least to the extent that the automated patient medical record system is included in their workflow.

14.3.1 Planning and Research

Project planning is required to coordinate development including the following:

· the project plan for development of the various subsystems including development order according to dependencies between them

· development of interfaces between the subsystems

· incorporation of hardware and operating infrastructure at the HMO and external to the HMO

· incorporation of new technology and research ideas into the system

· incorporation of national standards into the system as they are agreed upon

· planning for evolution of the subsystems, especially of the local system as new capabilities and chart documentation is added and as additional local systems are added.

As research of different areas becomes complete, the new ideas or technologies must be integrated into the automated patient medical record system (e.g., group communication capabilities, voice recognition, monitoring systems, etc.). Chapter 17 describes many of these research areas.

14.3.2 Infrastructure

Before the automated patient medical record and universal patient record can be implemented, computers and system software, networks and peripheral devices must first be installed in medical centers. Space requirements must be taken into account, such as how the computer system could fit into a small room. Rewiring may have to be done, possibly making it difficult, for a short time, to work at the work site during installation of the wiring.

System software and new hardware may have to be installed, including, for example, hardware and software for ATM networks, gigabit networks. workstations, pen computers, voice recognition, etc.

Installation of wiring, networks, computers and system software including operating systems, peripherals in medical centers is a major effort that must be coordinated with the development and installation of the system so the installation of hardware and system software installation occurs before installation of the application software. Likewise, the hardware and software for the CPR repository, source document repository and patient registry must be installed before it is needed in the development plan. However, it is also useful to follow the reverse philosophy also: to delay as long as possible the procurement of hardware and system software such as operating systems so that the newest technology can be employed or so that the technology has been around long enough to decrease in price.

Maintenance staff to support hardware and software installation and updates, and to manage controlled documentation could also be considered to be part of the infrastructure.

14.3.3 Interfaces

As subsystems of the automated patient medical system are being developed, the necessary interfaces between the subsystems as described in section 13.10 must also be developed and implemented as they are needed. Before an interface can be implemented, the associated hardware infrastructure must be implemented.

14.3.4 System Development

The systems and subsystems that will be developed are the following:

1. within the HMO and affiliated healthcare organizations

· initial local system

· regional system

· other local systems

· clinical research subsystem

· virtual system

2. Universal Patient Record

· CPR repository

· clinical guideline repository

· (patient registry)

· source document repository

14.3.5 System Evolution and Expansion

The system must be developed so it could evolve over time. For example,

· additional local systems could be added to a healthcare organization system

· the universal patient record network might be implemented and expanded over time from that shown in figure 6.4 to that shown in figure 6.5.

· systems in additional healthcare organizations to handle the automated patient medical record could be added and integrated with the universal patient record over time

· higher bandwidth networks could be integrated into the universal patient record

· higher bandwidth interfaces could be added within a healthcare organization

· advanced systems, such as research projects or diagnostic imaging systems (PACS) could be added.

The HMO system could be expanded to other HMO regional locations and other alliance and outside healthcare organizations. The universal patient record could be expanded to add additional CPR repositories, source document repositories; see sections 6.3 and 17.2.1.

14.3.6 Reengineering of the HMO

Caregivers must be trained in use of the system. They may have to change their prior work patterns. See chapters 11 and 12.

14.4 Sequencing Phases

The phases (or tasks) of the project must now be ordered and possibly be done concurrently dependent upon constraints. Phases are ordered based upon three types of constraints [4]:

· infrastructure must always be done first: infrastructure is the foundation for everything else

· technical constraints: imposed by the logic of the system

· managerial constraints: imposed by management for a particular reason.

The same approach can be used for ordering tasks within a phase project plan.

14.4.1 Infrastructure is First

There is an unequivocal answer to what to do first on a project--That is infrastructure. Infrastructure is the underlying foundation or basic framework of a system which must be done before the functional part of the system can be done. Or a definition I like: All those things you don’t see.

The problem with doing infrastructure first is that there are often no results which are apparent to upper management of the organization. A useful analogue is the building of a house. The infrastructure of a house is the engineering design and drawings of the house together with the foundation and structural elements of the house which hold the house together and keep it from falling (the foundation, the beams, trusses, joints, the side walls). But immediately after the infrastructure is finished, the occupants still cannot live there.

The infrastructure in the automated patient medical record system includes all the following:

· the analysis and design documents for automated patient medical record system--the controlled documents

· the automated patient medical record databases and programs

· the medical center and medical office buildings and wiring in these buildings

· the workstations, servers and networks within the medical centers and medical office buildings, and the support personnel for them

· the data center and the software and hardware systems, including operating systems, networks, data storage and file sharing mechanisms, data and file backup procedures, system logon and security systems, and the people who run these system

· the people who maintain hardware systems and programs, and the software and people who control new software releases

· the trainers, the user documentation and the training classes

· the reliability and performance requirements and the performance evaluation team

· the network connections to other software systems

· etc.

The infrastructure is time-consuming to do, requires a lot of thought, is costly, and is absolutely necessary. But upper management may not understand why the organization has spend so much money and time without receiving any tangible results.

Lots of people think that Microsoft does well because its software is so good. This may be true, but other companies have good software also. The one plus that Microsoft has over everyone else is that it controls the infrastructure! It makes the operating system for most of the computers in the world--some of those things you don’t see.

When building the automated patient medical record system, a health care organization must concentrate on one thing first--the infrastructure--for it holds everything else together!

Infrastructure should never be overlooked. PR (public relations) is important in this respect to inform people of infrastructure. PR is only important when you want people to be aware of something they don’t already know, and only often enough so they don’t overlook it when they need it!

14.4.2 Technical Constraints

Technical constraints are logical constraints. These include the following:

· One phase requires input from another phase and thus must be done later (e.g., the automated patient medical record system requires that the hardware for the system be installed before the application and requires that an infrastructure for log-on and security of the chart, both technically and legally, be established)

· A critical resource or resources, or one-of-a-kind piece of equipment, must be available for each of two phases full time and thus only one phase may be done at a time

· A phase in the project is required to be done by a particular date (e.g., by government mandate)

· Research is required to be done before a phase can be done, thus delaying it (For example, research is required into best methods of searching through the automated patient medical record for relevant information before this capability can be implemented).

14.4.3 Managerial Constraints

Managerial constraints are management imposed. These include the following:

· The project must demonstrate success early--thus a phase producing a high return on investment is done first

· Management wants to finish a particular phase by a certain date

· The project manager might want to do some easier parts of the project first so he gains a modicum of comfort with the project work.

Management constraints can be reversed while technical ones cannot. If circumstances require changes in the order of phases or tasks, then the project manager might consider negotiating with management to change a managerial constraint.

14.5 Incorporating Goals Within the Project Plan

Goals for project objectives and business requirements can be determined for the end of the project or strategically determined for intermediate points in the project. The intermediate goals can be evaluated in the overall project plan at a gate (e.g., those places marked with a ‘G’ in the example project plan in figure 14.2). Gates, and goals, could also be included within project plan of a phase.

References

[1] David I. Cleland, William R. King, editors, Project Management Handbook, Van

Nostrand Reinhold, 1988, article by Michael K. Gouse, “Overview of Project Management Applications”.

[2] Robert Buttrick, The Project Workout: a toolkit for reaping the rewards from all your business projects, F T Pitman Publishing, 1997.

[3] Joan Knutson and Ira Bitz, Project Management: How to Plan and Manage Successful Projects, AMACOM (a division of the American Management Association), 1991.

[4] Robert K. Wysocki, Robert Beck, Jr., David B. Crane, Effective Project Management: How to Plan, Manage, and Deliver Projects on Time and Within Budget, John Wiley & Sons, Inc., 1995, pp. 156-158.

NEXT
TABLE OF CONTENTS

Comments? mailto:Michael.McGuire@abac.com