11. Reengineering the Healthcare Organization
for the Automated Patient Medical Record

11.1 Project Context: Business Reengineering of an Organization for a Project

In the Business Reengineering step as shown in figures 2.2 and 2.5, employee workflows for the project (such as our automated patient medical record system) are determined. These are determined for the various types of employees using the system (1) from talking to employees, (2) from organizational business policies on how the organization should function, and (3) from the anticipated new way the organization should function (in our case, as described in chapter 8 describing the future environment and system).

Defining the Workflows of Various Categories of Workers

Different categories of workers impacted by the project are identified, such as listed in section 4.2. For each category of worker, a workflow is developed. Based upon the workflows, user interfaces for each automated system developed or changed by the project are described. When interfaces between automated systems are identified they are recorded.

Defining Business Policies of the Health Care Organization

A business policy is a policy to be applied throughout an organization. Business policies may be implemented by changed employee procedures, thus effecting workflows and user interfaces—see section 11.4. Business policies may also be implemented by storage of data on database, by code, or by interfaces between systems, with specifications for these in later steps, which is discussed in other chapters.

Defining Business Objects to be Used in the User Interfaces

In order to make user interfaces easier, it is useful to first define “business objects” that are objects that the users use in real life, e.g., patients, the patient chart, etc. User interfaces may be defined in terms of these business objects. See section 11.4.3, Model User Objects. These business objects are used both within any new user interfaces and within databases.

Defining the User Interfaces

The user interfaces may be defined in terms of screens, written requirements for these user interfaces, or both. For vendor systems, only written requirements are likely to result. For a new system, a complete description of the user interfaces for the entire system would result; for a changed system, only a description of user interfaces for the changes. When user interfaces are defined in terms of screens without any underlying functioning code or databases, this is referred to as prototyping.

Keeping User Interfaces in Synch With Databases

Most all of the data displayed or input through user interfaces comes from or will be stored on databases. Thus user interfaces and databases must be kept in synch. Additional data may come from direct interfaces with other systems; this data must also be identified.

11.2 Prototyping

Prototyping is the process of developing and interacting with a partial version of a system in order to gain user feedback and to evaluate feasibility. A prototype appears to provide all the functionality of the final system, but parts of the system are left out (e.g., there are likely no databases, no interfaces to other systems, etc.).

Prototyping is vastly misunderstood. To explain prototyping better, we use an analogy of building a house.

In designing a house, potential buyers, the architects, civil engineers, plumbers, electricians, city building code people and others get together. Blueprints are created to capture the agreed-upon design of the house, including floor plans, foundations, roofs, structural components, electrical fixtures, etc.

A scale model of the house may be created for potential buyers to look at. Potential buyers may look at the model to see if this is the kind house they would want to buy.

Then the contractors, carpenters, plumbers, electricians and others get together to actually build the house. Building the house is based upon the blueprints.

Now, by the time the scale model was created, lots and lots of hard work has already been done. This work includes all the thought-work in designing the house along with buyers, electricians, plumbers, civil engineers, etc., and in doing the blueprints. The building of the house may in fact be a much easier process than the design part, with the building part only being hard because of the time consumed to do it. Of course, you could have created a quick scale model without the design process, but there is no guarantee that such a house would be structurally sound, fit the appropriate lot or pass building inspections.

What is the purpose of the scale model of the house? To have potential buyers look at the proposed house. These potential buyers would determine if they liked the house or not. If enough potential buyers liked the house, then the contractor probably would go ahead with building one or more houses.

On the other hand, if no potential buyers liked the scale model of the house, then the contractor would probably either (1) scrape everything! or (2) start all over again with the design process (and probably create a completely new scale model)!

What has this to do with the automated patient medical record system? Well, the design part up to creating blueprints for the house is equivalent to getting users, database people, technical people, caregivers, patients, and others together to design the system, and the business analysts and software engineers to write all the specifications for the system. The scale model of the house is equivalent to creating a prototype of the automated patient medical record system, usually including screens. And the actual building of the house is equivalent to actually building the automated patient medical record system.

For the house, potential buyers look at the scale model to see if this house is acceptable to them. Likewise, for the automated patient medical record system, potential users look at the prototype to see if the system is appropriate for them--the results of this process are similar that for the house: (1) the users either accept the system, only making cosmetic changes that do not structurally change the design, (2) everything is scraped, or (3) the design is started over again.

What have we learned here about prototyping?

A lot of design work precedes prototyping, and if the users do not like the prototype, then what is likely to happen is that the previous design will be scraped and the design process must be started all over again!

What are the advantages of doing a scale model or a prototype?

If we started the building of the house instead of doing the scale model for the potential buyers, then many houses may have been built that no buyers would have bought!

Likewise, if we started building the automated patient medical record system instead of doing the prototype for the potential users, then a system may have been created that few users would want to use!

A prototype is not to be confused with a conceptual view. A user interface can be presented as a conceptual view, but it must be treated as such: the conceptual design is presented to generate or demonstrate ideas that provide input in the design process. A "conceptual view" is like a "rough sketch". A "prototype" is a potential product that must fit together in all respects.

11.3 Defining Changed Workflows

Reengineering an organization as a result of a project involves (1) identifying the future users of the project and its software systems, (2) determining their current workflows, and (3) reengineering their workflows to anticipate workflows after the project is completed. For our automated patient medical record system project in an HMO, the future users include inpatient physicians, outpatient physicians, inpatient nurses, and medical assistants. Future workflows are determined for each category of user.

For the current workflows,

· identify current processes within the workflow

· identify processes with a high potential for improvement

· identify processes of high value to patients or caregivers

· identify the roles and responsibilities of individuals in the organization involved in the workflow

· understand the goals of the overall organization

· understand how departments work together and how the organization works with outside organizations

· provide a mechanism for extensive employee input into workflow changes, as changing workflows is a social, as well as a technical and business process.

For the future workflows,

· develop new, more efficient, processes within the workflow identifying processes that should be kept, added, changed and eliminated while preserving the relationships between the processes

· align individual roles and responsibilities with those of the business, modifying processes if required

· optimize interdepartmental communications and communications with other organizations

· formulate a complete blueprint for a revised workflow

· design the automated system to support this workflow and overall goals of the organization

· allow enough room for employee initiative, expertise and creativity, and control over their own destinies

· provide fallback modes of operation when things go wrong (such as computer failures, power failures, etc.) or unusual circumstances (such as emergency situations)

· set future ways to measure and monitor success of the system with respect to the workflow and organization.

A diagrammatic method for modeling current workflows and new workflows in detail are Data Flow Diagrams (DFDs). For example, see figure 11.1 for a DFD showing a simplified workflow for a nurse practitioner (NP). In the DFD [1], a named (curved) line represents a data path. A bubble (called a process) portrays transformation of data. A straight line represents a data store (a data base, paper document or other medium of recording information).

A nurse practitioner sees patients or makes phone calls to patients. In all her major activities, the nurse practitioner consults with a lead physician or follows protocols. Before a patient comes in, she reviews the chart. When the patient comes in she examines and interviews the patient, usually creating a History and Physical or Progress Note document to be put in the chart. Nurse practitioners can make orders or perform procedures according to protocol; she documents these activities. In the last part of the patient encounter, she gives advice to the patient, documenting this information. After the patient leaves, she may complete all her documentation on the patient, and she puts the documentation in the chart.

Reengineering workflows has been referred to as Business Process Reengineering (BPR). Although popularized by Michael Hammer and James Champy in the 1993 book, Reengineering the Corporation: A Manifesto for Business Revolution [2], BPR is quite old. In fact, the process of workflow analysis has been automated, using more sophisticated models than DFDs.

There are at least two types of software systems to model workflow: workflow systems, where a business is described by processes, discrete activities that make up the business practices of an organization or of a part of a business, and where these processes are analyzed, and discrete event simulation [3], where, in addition to defining the business processes, the time of each process takes is statistically evaluated and the total expected time of a workflow can be evaluated. A standard for the former, workflow systems, has been established by consortium of companies by the Workflow Management Coalition [4].

Within the workflows for each category of user, the use of existing and new automated systems is then identified. For each new automated system, an analysis must then be done for each class of users to define appropriate user interfaces, with commonality between interfaces also identified, so these parts of the user interfaces for the new automated system can be combined. For each existing system, requirements for changes to user interfaces or for system interfaces with other automated systems are identified. Section 11.4 describes a process for defining user interfaces in more detail.

11.4 Implementing Business Policies

Through workflows, user interfaces, databases, code or interfaces between systems, organizations implement important business policies. For example, one HMO business policy might be the rules for assignment of an HMO member with a primary care physician.

In order for an organization to keep control over the implementation of business policies, documents describing organizational and project business policies should be developed and kept up to date. Such documents should describe how the policies will be manifested by databases, program code or tables, by user interfaces, by interfaces between systems, and the manual operations of employees in the organization.

To not have such documents would require that implementation of the business policy be under the control of computer programmers. The project business policies document should be used to test the project-automated systems to verify that all business policies have been implemented correctly.

A Business policy consists of the business rules for implementation of the policy in total in the organization, including the implementation of the policy within organization automated systems and databases. Thus documentation of a business policy combines business and information technology information.

Consider again the business policy defining the rules for assignment of HMO members with primary care physicians. This might be implemented operationally, telling employees how to talk to a patient to encourage that patient to select a primary care physician; implemented by adding information to databases, such as including information on databases to record the patient assignment with a primary care physician; implemented through user interfaces, by providing fields on the screen to allow input of the assignment; and implemented through code, which incorporates the rules for assigning the patient to a primary care provider in code.

11.5 Defining User Interfaces

This section assumes that Graphical User Interfaces (GUIs) are used for all user interfaces. The next chapter discusses other possibilities and why this assumption of use of GUIs was made.

Reference [5] describes a method for designing, evaluating and refining the design of GUI based software systems, which is presented in summary form in this section. This model, referred to as GUIDE for “Graphical User Interface Design and Evaluation”, is diagrammed in figure 11.2 [5]. Boxes represent processes and lines represent how products are produced by one process and input to another. The steps of this process of defining a GUI user interface is presented here for the automated patient medical record system.

11.5.1 Define Users and Usability Requirements

The principal users of the automated system are identified and described. For the automated patient medical record system, users can be put into the following classes:

· outpatient physician

· hospitalist/inpatient physician

· outpatient nurse

· medical assistant

· ED triage nurse

· nurse practitioner

· physician assistant

· inpatient nurse

· unit assistant

· ED physician

· ED nurse

· advice nurse

· appointment clerk

· case manager

· health care service representative/ombudsman

· quality manager

· medical researcher

· ancillary department personnel

· computer system support.

For each class of user there should be an evaluation of the following so the system can be designed to best accommodate each class of users:

· type of users (direct user of the system, indirect user in that other people use the system for the person, remote user who works at a different location than the system, support user who helps other users)

· mandatory or discretionary user

· probable computer experience and skills

· motivation for using the system.

For example, direct users must be computer-literate, for indirect users an efficient communication mechanism must be set up to communicate information from the caregiver to the input specialist, remote users require set up of remote connections and support users must be provided the proper system software. Mandatory users have to be computer literate. The system must be developed to provide payback to each user class so they are motivated to use the system.

For each class of users, usability requirements should be established. According to Jakob Nielsen [6] “usability” consists of five characteristics:

· Ease of learning: How easy it is for a new user to learn the system.

· Efficiency of use: How fast an experienced user can accomplish his or her tasks.

· Memorability: If the user used the system at an earlier time, how quickly she can pick it up at a later time.

· Error frequency and severity: How often the user makes errors and how severe these errors are.

· Subjective satisfaction: How much the user likes using the system.

These characteristics could be used as a quantitative measure of how effectively each category of user was using the system and could later be used to evaluate the GUI design. The most effect standards and input styles could be evaluated for the sets of users, resulting in the production of a style guide that can be used for the system.

Identification of the user classes would enable work tasks for each class of users to be developed and user objects for each class of users to be identified.

11.5.2 Model User Tasks

The purpose of a computer system is to help each class of user perform their tasks (i.e., their jobs, their workflow) more effectively and efficiently while allowing the users to concentrate on their jobs. This step uses the workflows described in section 11.2 to identify how a class of worker performs his job. Parts of the workflow dealing with the automated system are identified and the user interface is viewed in the context of these work processes.

11.5.3 Model User Objects

The intent here is to create real world independent “business objects” that correspond to the objects the user uses in real life to do his or her job. These will be objects within the user interface, thus enabling the user to think in the same terms as he or she currently does. Section 12.2.2 in the next chapter explains this idea in more detail.

For the automated patient medical record system, these objects might be as follows:

· patient demographics information

· patient lists

· patient clinical summaries

· encounter synopses

· chart display

· cases

· orders

· chart documentation input

· appointments

· e-mail/messages

· medical references.

These user objects would be used in the GUI interface.

11.5.4 Match User Interfaces with Databases

What is displayed through user interfaces is (a) data from one or more databases, (b) data input by the users, (c) transitory data determined during display of the information, and (d) data from other applications coming via interfaces (such as via a network or magnetic tape). However, databases should not be developed based upon user interfaces in the Business Reengineering step but rather upon business objects and the relationships between these business objects determined in the Business Analysis step

These business objects which define databases and the relationships between these business objects are often described by entity-relationship (E-R) diagrams. See section 13.7.

Some of the databases used by the user interface may already exist in the organization and some may be new and created just for the application. Thus an important part of the process of defining user interfaces is defining data within these new databases and creating additional user interfaces or changing user interfaces so the correct data is collected at the right time. Again, some information may be collected to support organization business policies.

There are corporate databases which may be used across many applications and application databases used by only the new application. Further, an application database may migrate to become a corporate database if it is determined that it could be used by other applications. When databases are split amongst different computers, whether they are application or corporate databases, we refer to them as “distributed databases”, often connected via a network to the computer running the application.

Databases are often optimized to support on-line operations (i.e., to support user access to application systems through the user interfaces).

For more information on databases, see sections 13.7 and 13.13.

Matching of user interfaces with databases also involves implementation of business policies and business rules for the data: In order to have good data, business rules for the data must be established at the time the user interface for entrance of the data is created. If the user interface allows data values that the business rules do not allow, then there almost certainly will be bad values on the database.

11.5.5 Define Style Guide

One basic principal of quality software design is to have a consistent and useable set of screen display and input standards as this decreases the complexity of the system and makes the system more intuitive for the user, making the system more useable. Developing a style guide based upon user objects does this. In addition, it gives the users an impression of a uniform ‘look and feel’ for the system. And it makes program maintenance for programmers much easier, as code controlling the user interface can simply be replicated and used over and over again. The style guidelines chosen must enhance usability requirements previously determined.

Some important points are the following:

· The system should never get in the way of the caregiver doing his or her job: Make the system transparent so a user can forget the system, use it intuitively, and concentrate on his job.

· Ordinary users and technical users of software systems are different: Ordinary users like simplicity while technical users may or may not be comfortable with complexity.

· Make the most used parts of the system conspicuous and very simple to use, while hiding the most complex parts: Make the fundamental functions obvious and easy to find and use. It is also okay to have powerful complex functions, but they should be hidden from users who do not need them.

· Consistency: Have absolutely consistency of everything, so users know exactly what to expect of the system at all times (e.g., have scroll bars, list selections, etc., all work the same, as identified in the style guide).

Consistency includes consistency of error messages. Wherever the same named field appears on any window or screen, it should give exactly the same initial result (e.g., a date is a date, an address is an address, a city is a city, and a zipcode is a zipcode no matter where it appears in the system). This consistency is accomplished by first doing “single field” edits, using the same computer program code for any like field, and only then doing “relational” edits, edits which combine two or more fields. Relational edits could be ordered too, with edits within the same line done first and then edits between lines, edits between sections of data on the screen, etc. An important first step though is doing the single field edits first, so the user, for example, doesn’t enter a zip code correctly in one place on the screen and makes exactly the same error in another place, he gets exactly the same error message. Additionally, edits (e.g., all single field edits) should be done in the order the fields appear on the screen top to bottom, left to right, so, when the user corrects one error, it goes to the next one, if any.

· Initially on each window or screen, put the focus on the upper left part of each window or screen: A window or screen is potentially very large, containing a large amount of information. The user often does not see the whole area. Simplify the window or screen and hide the complexity on the by putting the absolutely essential stuff in the upper left part so, most of the time, the user only has to look at that. If she needs more information some of the time, she can then find it on other parts of the window or screen.

11.5.6 Design GUI

The GUI design is developed from three main products:

· The user object model

· The task model

· The application style guide.

The objects making up the GUI design comes from the user object model. Windows would be in the style determined by the style guide. What the entire system must support are the workflows in the task model for the various classes of users.

11.5.7 Prototype and Evaluate GUI

Prototyping is the process of developing and interacting with a partial version of a system whose interface functions the same as the final system in order to gain user feedback to evaluate usability. A prototype appears to provide all the functionality of the final system, but other parts of the system are left out (e.g., updates to databases, interfaces, etc.).

The reasons for using a prototype rather than the real system are the following:

· the prototype system can be developed long before the real system

· the prototype system can be changed more easily than the real system

· the prototype system is more controllable and predictable than the real system.

Developing a prototype system, enables users to test out and critique the system. It enables business process analysts to determine when usability requirements are not met. When problems are found, the design must be changed, and the prototype changed and re-tested.

The purposes of prototyping are to do the following:

· validate the style guide

· reach agreement on how the GUI is to support each task in the workflows

· explore the appearance and behavior of each screen

· satisfy usability requirements.

11.5.8 Tradeoffs

In developing user interfaces from workflows there are many tradeoffs:

· Different locations of the organization may want different workflows: You either have to have user interfaces which accommodate these many different workflows or you must change the workflows of one or more locations.

· The organization may want to standardize workflows: An organization may want to standardize on a particular user interface to force everyone in an organization to use the most efficient workflow or enforce a required process (e.g., collect information required by a regulatory organization).

· What may seem like the best workflow may later not be: An anticipated workflow may have to later be changed, possibly making the associated user interface obsolete.

· User interfaces can be general, accommodating many different workflows; or can be tailored to a specific workflow: More general workflows are more likely to succeed.

· A system which is extremely flexible may be more costly to develop and may be more difficult to train, use, and maintain.

· Systems with user interfaces that do not accommodate a workflow will not be stable: Either the workflow will change or the user interface will not be used as expected.

· Accommodating workflows is just a starting point: Many things change in an organization over time.

· To insure that a user interface is used, you must have user buy-in to the user interface by a large number of users: The best approach is to have significant involvement of a large number of users in the development of the user interface, with consensus agreement that they can “live with it”. Beyond that, you need good facilitators to work with the users, as well as user interface designers who recognize good designs and are very flexible in absorbing, and accepting, other people’s ideas.

11.6 Workflows and the Disadvantages of a Super Competent Employee

It is important to recognize all workflow activities, especially those that are hidden. For example, a workflow may consist of activities A, B, C, D and E, but a super competent employee may automatically take care of B, C and D for the department, so the needs for B, C and D may be hidden to a naive manager.

For example, a Spanish-speaking physician may cover for the need of a department to serve Spanish-speaking patients. But what the department really needs instead is to have Spanish-speaking interpreters who can cover many different departments, not just one.

By taking all the Spanish-speaking patients, the physician may be assigned predominantly to patients who speak Spanish, and may thus be penalized for her special capabilities by being overburdened with patients. Further, Spanish-speaking patients may all be directed to her department instead of a more appropriate one. But the need of having interpreters for all departments does not go away.

If the physician leaves, if the physician is unavailable or is replaced by an average competence employee, then all the missing processes (and needs) resurface.

Therefore, it is important for managers to recognize real needs and processes, which again, can be covered up by having super competent employees. Sometimes it is better to fail than to patch things up through super competent employees! Sometimes it is better to have average competence employees so missing processes can be identified!

Super competent employees need to be treasured. They need to be recognized for the special contribution they make, and they should never be penalized!

11.7 Usability, Response Time, and System Performance

Usability is a quality of a system to assist a user in doing his job, and to be easy to use intuitive for the user. Response time is the time for an automated system to respond back to the user upon entrance of input; bad response time may disrupt the user in doing his job. Good system performance is the ability for the system to handle all its users and perform all its activities in a timely manner.

Caregiver scenarios are useful for the analysis of all three of usability, response time and system performance. A scenario is a common workflow of a user during which the user uses the automated system; an example is the workflow for an outpatient physician seeing a patient for an urgent care visit while using the automated system, or the workflow of an inpatient nurse in caring for a patient in the hospital while using automated system.

Taking the set of common scenarios and analyzing the automated patient medical record system with respect to each of these scenarios enables the automated patient medical record system to be changed to maximize usability of the system.

Also, potential system architectures for the automated patient medical record system can be selected based upon which ones can best handle the scenarios together with all the other supporting activities of the system (given the relative frequencies of occurrence of each of the scenarios). Once potential system architectures are selected, these architectures can be simulated in a testbed, a smaller scale hardware and software system that mimics the automated system. Response times and other system performance characteristics can then be estimated through testing within these testbeds with subsequent determination of which of these architectures works best.

Once the system architecture is selected and the automated patient medical record system is created later in the development step, the scenarios can then be used in scripts to control performance testing. A script mimics the input of a caregiver in using the system; using a number of scripts together can mimic a large number of users using the system. During performance testing using the scripts, network throughput, disk drive efficiency and other elements of the system can be measured, thus identifying bottlenecks in the system. Through correction of these bottlenecks, system performance can be enhanced, including lowering of response time.

References

[1] Tom DeMarco, Structured Analysis and System Specification, Yourdon, Inc., 1979.

[2] James Champy and Michael Hammer, Reengineering the Corporation: A Manifesto for Business Revolution, New York City: Harper Collins, 1993.

[3] Averill. M. Law and W. David Kelton, Simulation Modeling and Analysis, New York: McGraw-Hill, 1982, 1991.

[4] Address: Workflow Management Coalition Office, 2 Crown Walk, Winchester, Hampshire S022 5XE, United Kingdom. Also on the Web at http://www.aiim.org/wfmc/mainframe.htm.

[5] David Redmond-Pyle, Alan Moore, Graphical User Interface Design and Evaluation (GUIDE), Prentice Hall, 1995.

[6] Jakob Nielsen, “What is ‘Usability’?” from column, “Web Usability: Why and How.” in Design/Usability, September 14, 1998.

NEXT
TABLE OF CONTENTS

Comments? mailto:Michael.McGuire@abac.com