A radiologist surveys his department as he contemplates the opportunities and difficulties involved in front-end integration. The staff members are at their review and diagnostic workstations. There is a picture archiving and communications system (PACS) and a digital dictation and speech-recognition system in use, along with a hospital information system and a radiology information system. Meanwhile, radiologists and other clinicians are using mobile diagnostic solutions such as handheld computers and web portals to view tests and collaborate with one another on diagnoses and treatment plans.

Some of the software entities involved talk to each other, but most do not, the radiologist admits. As he gestures in the direction of the row of monitors occupying the table of one workstation, he says, "The good old days: it used to be so simple. You did your reading, you filled out one form, and you were on to your next case; now, I grab the wrong mouse half the time."

Though the radiologist may be indulging in a bit of nostalgia, he hastens to add that he has no desire to return to the good old days. That one form that he mentioned, for instance, was not only difficult to fill out, but was a weak link in a chain of patient information. It was both prone to error and time-consuming (not to mention expensive) to amend. Over the past decade, the radiologist has participated in dramatic transformations of his department, and he knows that software has improved patient care and increased productivity in countless ways over the course of time.

Still, by hearkening back to a simpler time, he expresses a desire common among radiology departments for less complicated ways to get more work done while maintaining an impeccable standard of care. He, like others, is unconvinced of the necessity of sacrificing ease of use for power, or comfort for efficiency.

Another radiologist bemoans the challenges of balancing his desire to adhere to aggressive diagnostic schedules with having to keep himself open to other clinicians for consulting on nonroutine cases. The computer systems that support his department are optimized for what amounts to assembly-line work, he explains. They are also characterized by linear work flows and asynchronous information sharing, but when a nonstandard case calls for heavier collaboration among radiologists, clinicians, and radiologic technologists, the system cannot cope. That is because collaboration work flows tend to loop around, and they require a high level of data synchronicity and simultaneity of information exchange.

Humans rush to fill the gap, naturally, and the cases are handled, but everyone pays the price in the form of excessive tasks that are often frustrating to undertake. In describing the characteristics of an integrated PACS, the radiologist says that availability and amiability are just as important as accuracy.

These radiologists are not alone in their demand for more helpful systems. Integration problems affect people at every level: executives, information-technology departments, clinicians, and patients. Health care businesses allot a significant portion of their budgets to maintaining rough, multivendor assemblages of information products. As these systems expand to accommodate more patients, track more detailed data, and encourage more collaboration among health care professionals, people are beginning to realize that their information systems are both insufficient and indispensable.

They are insufficient because they are rarely flexible enough fully to accommodate the entire range of work that medical staffs perform, and because they fail to integrate well with other vendors' products, yet they are indispensable because they contain the valuable data collected over many years and are familiar to users throughout the organization.

Front-end integration can be a critically important step toward ensuring the accuracy, speed, and quality of diagnosis, reporting, collaboration, communication, treatment, and billing. Because such integrated systems provide people both inside and outside the radiology department with important information, however, their introduction into the health care setting may require changes in time-honored roles, work practices, and relationships. In other words, front-end integration initiatives can subtly alter the way that medicine is practiced. Complex software, such as that found in the kind of information system that can integrate work flows in and around a radiology department, has the power to alter the organization that it is meant to serve. In this sense, integration can be an organizational re-engineering project in sheep's clothing. Maybe the changes that follow will be good, and maybe they will be bad; either way, it is critically important to anticipate them and, when possible, channel them in ways that will be most beneficial to the organization, its patients, and its staff. As with any complex system, one must beware of the new problems that a new solution may spawn.

It can be tempting to begin an integration initiative by examining products to determine their capabilities and then proceeding from that point. This could represent a costly mistake. The appeal of a new technology has a way of blinding people to the concrete, human context in which this technology will exist. People love the new technologies because of their transforming power, but this alluring aspect of their nature means that technologies do not simply fit into an environment. They change the environment as well.

A better approach would be to step back and take stock of what people in the organization need, measure their tolerance for change, review the available technologies, and develop a plan that will help smooth the adoption of the right solution. A modest initial investment of the time needed to examine the context and needs of users can pay high dividends later. Software promises so much, but  it can require tremendous resources to redeem those promises. It is critically important to ensure that product features are useful and usable before committing the organization to any particular technology plan.

Nine Questions

In my interaction-design practice, I have observed that organizations can avoid considerable technology-enhanced consternation when they ask nine basic questions in sequence. These questions may help those who answer them ensure that newly adopted technologies serve, rather than thwart, the goals of people and the objectives of organizations. These questions are in no way exhaustive. There are thousands of questions that need to be answered to ensure that a front-end integration initiative goes well, but these nine offer a high-level framework for staging an investigation into the possible implications of promising, yet potentially disruptive, technologies.

1. With whom do we exchange information, both inside and outside our department? Some people generate information and others consume it, but most people do both. When contemplating front-end integration strategies, it is critically important to understand who these system participants are, where they are situated in the various work flows inside and outside the department, and what powers influence their information exchange.

For an integration effort to pay real dividends, it must accommodate a certain amount of growth. When identifying system participants, it is critically necessary to recognize that today's participants are not necessarily tomorrow's. For instance, front-end integration can have implications for radiologic technologists, radiologists, radiology administrators, cardiologists, referring physicians, administrative staff, information technology department staff, billing staff, executives, and others. If people outside the radiology department are capturing or supplying information, the department needs to make sure that its system works well with the systems that they use.

2. Why do people interact with our current system? What is motivating people to use the system? Humans, being human, will take action to subvert the new system if this helps them achieve their goals. Rather than achieving a form of integration that simply automates the misery of current work flows, departments should determine the goals underlying the current work flows and then determine whether the intent of those work flows can be satisfied in more direct, less cumbersome ways.

Departments undertaking a technology-enhanced work-flow transition should beware the moving target that tasks can be. For instance, when sharing film with a referring physician, a radiologist may literally shuffle the deck to ensure that the clinician's attention is turned to the most critical material. In an integrated system that provides digital images and reports to a clinician, it is important to satisfy the goal of such a shuffle, while also taking advantage, perhaps, of the additional capabilities of a computerized system (such as metainformation that can help people understand the attributes of the files in ways that make sense to them).

Of course, not all goals are worth satisfying, and not all information is the responsibility of the newly integrated system to deliver. Consequently, this phase requires a sanity check to ensure alignment with the departmental mission and resources.

3. What information does the current system generate, and upon what information does it rely? Once system participants and their goals have been identified, it is time to analyze the classes of information that they may want to share. At this point, the department should not worry too much about whether this is analog or digital information, or about whether it resides in one database or multiple databases. While this knowledge is critically important to capture and address, the point of this step is to catalog the sorts of information that people need to get their work done. That makes it possible to undertake an integration project that will ultimately supply that information in contexts that are meaningful to the whole range of system participants.

When the classes of information used by system participants are known, the department should break that knowledge down into its fundamental parts, thus defining the information assets of the system. These will include images, reports, patient records, unstructured notes from technologists, schedules, and much more. Do system participants generate and use this content whole, or do they use only parts of it? Do they combine it with other information, including their own? These are important questions to answer before creating a system to serve their needs.

4. How is information

currently generated, captured, and made available? Departments should determine how they perform these tasks at present; at the same time, they should reach beyond the department's boundaries and document the relevant information supplied by others whose needs the system must satisfy.

It is worthwhile to document nuance. Is one kind of information generated by multiple people? Is it compiled by another person altogether, working in another department? What procedures do these people follow? What technology helps them? How long does it take to produce and deliver this information in a usable format? Do the people involved believe that there is waste in the process? Do they have ideas for improvements?

5. What are our priorities for front-end integration? Equipped with an understanding of its information-related needs, the department can undertake a priority-setting exercise. This should take into account not just financial and technical considerations, but the needs of system participants and the overall objectives of the organization.

6. What are the available technological solutions? Once the department knows its integration needs and their relative importance, it should survey the capabilities of available integration solutions. In reviewing the relevant literature, visiting trade shows, or speaking with product vendors, department representatives will be able to address their specific needs (rather than features that may sound good, but that may not satisfy the goals of system participants and the department as a whole).

The department should be careful not to let this process get out of control. While a solution survey may be a useful way to determine the acceptability of certain technology solutions, at this point, it is still too early to begin signing agreements (although a certain amount of feasibility testing is valuable). Rather, this is the time to develop an understanding of the capabilities of technologies, becoming equipped with the information that is helpful in modeling a better system of information exchange.

7. What would an optimal system look like? The department, at this point, knows which information people need, how they produce it, and why they need it in the first place. It also has some ideas about how technology might be able to improve the situation. The time has come to peek into the future to determine the characteristics of an optimal system.

It should be kept in mind that what people are doing now may not be what they will do with a freshly integrated front end. For instance, it may be the case that radiologists are spending considerable time assembling images, reports, notes, and other information, then sending it off to other system participants. The department's investigation may have revealed that radiologists do not like to assemble this information and that it could be done better through automation, so long as the end result is sensibly assembled information that is understandable and accessible to all relevant system participants. If this is the case, then the department must stipulate that its optimal system will not require radiologists to do such assembly; rather, the software should do it. By capturing this requirement, you now have a  key attribute of acceptable integration.

This step may require the department to examine (and even re-shape) a system of roles, relationships, information, procedures, and technologies that can produce and deliver information as efficiently and effectively as possible for the purposes already identified. This may not always involve using the most appealing technology available. If the department discovers that the most effective way to achieve a specific goal is to email an image to a clinician, then it may not be necessary to expend resources obtaining a sophisticated tool that would do the same thing (but require significantly greater funding and training). The most appropriate solution should always be sought.

Ultimately, the model created for the future system should provide a coherent set of answers to nine further questions: 

• what roles will have to be filled  to meet the needs of system participants;

• how will these roles balance one another in the overall organization;

• what will motivate people to cooperate;

• who will be responsible for monitoring and resolving conflicts;

• what customs, principles, and processes will guide decisions;

• what new training or reporting structures will be necessary;

• how will the system balance the goals of staff with the objectives of the organization;

• what measurements will be applied to the performance of the new system;

• what can be done using software and what is best left to other means?

Departments should also consider developing toolkits of best-known methods for system participants to use. Since integrated systems require an unusual degree of cooperation among a range of parties inside and outside a department, departments should foster understanding of the project and support for it both inside and outside the department.

8. What techniques and technologies will satisfy the requirements of the model? This is when products are specified, purchased, delivered, installed, tested, and implemented. There are many considerations to bear in mind at this stage. What is key, though, is anticipating how these products will have to be adapted to meet specific needs. It is just as important is to develop a plan for keeping the department going as the new system is introduced. Every organization has its own speed limit and tolerance for change, which must be respected. In addition, there can be countless interdependencies among functions, technologies, and objectives. That is why it is important to leverage previously useful processes, as much as possible, to ease migration from the old system to the new.

9. How can we determine the effect of integration? As novel technologies are introduced, unexpected processes may emerge. Departments should be observant and note the differences between expectations and results. Toward this end, it is necessary to take time to measure the performance of the new system. Doing so will provide the department with the means to determine its return on investment, as well as the effect of integration on such important issues as quality of care.

Measuring performance against the department's predetermined success criteria also provides information that could lead to making further changes to the system. Of course, not all feedback will be in quantitative terms. Feedback of a profound kind is sometimes difficult to anticipate using a predesigned questionnaire. Therefore, it is important to also employ qualitative research methods in order to understanding what people really think. Then, if the organization decides to alter the system a second time, it should go through the entire nine-question process once more to ensure that the intended changes make sense within the new context.

David Fore is vice president, consulting services, Cooper, San Francisco, Calif.