The success of simulation and virtual reality in medicine will depend on our ability to develop products which meet the needs of our customers: educators, physicians, students, and other scientists. To achieve this end, we have to make and accept significant limitations in the design, development, and production of medical simulation devices. The process of defining and selecting among alternatives can be difficult for individuals who are caught up in the excitement and unlimited potential of a new field. If we look at these decisions as tradeoffs between competing alternatives, it can help us to analyze the impact of our decisions. This presentation looks at some of the choices concerning specific market needs, user requirements, and technology and design features. We will examine some of the areas where conflicts can arise, and suggest how to arrive at useful compromises.

The ability to mimic reality is not required to create a simulation which can provide students with an environment in which they will learn important skills. It is important to the user to feel as if they are interacting with a real patient. In order to accomplish this we must understand what defines the experience, and how closely clinical reality must be reproduced. We must also understand what skills will be learned, and how to measure them. Much time and money can be wasted reproducing clinical clues which are irrelevant to the learning which the simulator is used for.

Should the simulator use “real” cases or “simulated” ones? Can the cases be “typical,” or should rare pathologic cases be employed? An important element in the design is the need to avoid incorporation of misinformation in the simulation. All simulators are by necessity a rough approximation of reality. The possibility of creating misleading clinical images or “practice” situations is a real danger. Care should be taken to avoid this level of oversimplification, or to clearly identify when this can occur. The information content should meet or exceed the level available from other sources such as textbooks, videotapes, and CD-ROM’s. The characteristics of the image must reinforce the illusion of reality, and must not mislead the student. This requirement for clinical reliability introduces some absolute standards for image quality, simulation response time, and critical values. This set of parameters can serve as the “finite box” which surrounds the simulator project, and allows tradeoff decisions to be made in a broad context of clinical and educational use.

As we learn more about how simulators will be used in medical education, we understand better the criteria which can define successful development. At the most basic, the simulator should allow the student to acquire clinical skills and medical information. This simulator will allow the student to learn these skills in a shorter time, at lower risk to themselves or patients, and in a more “practical” or realistic manner. More advanced simulations will enable students and practitioners to enhance their clinical knowledge, and to acquire experience with a broad range of patients and illnesses.

In developing specifications for new simulators, a useful model for understanding these issues is to look at each element as a “trade-off” between several alternatives. This model enables us to look at the explicit potential gain and loss from a variety of decisions, and to understand their impact on future directions. This helps to avoid “black and white” thinking, which does not represent reality. A useful feature of this analysis is that it can clarify the risks and benefits inherent in what may appear to bea simple decision. If progress stalls, a re-examination of these decision points can help lead to a new avenue for potential solutions. Typically, a product development program will progress along multiple lines simultaneously. At some moment these lines should converge and lead to a design stabilization decision. Non-stop innovation, or unceasing product design changes, can sink even the best product development team. A clearly defined goal, and recognition of these limitations is critical for progress to be achieved. Careful records and analysis of the variables encountered in the development process can allow for resource allocation to be altered based on results achieved. Doing this can help us to assess the magnitude of the tasks which will be required for completion of the project.

The process of engineering a successful implementation of simulation requires a careful analysis of the way which users will interact with the simulation. The procedures followed to develop the analysis are many and varied. In the development of the UltraSim® ultrasound simulator we started the development process by asking ultrasound educators
 

what an ultrasound simulator would look like, and how it would function. In the early stages of this process, our own ignorance about clinical ultrasound education actually turned out to be a benefit. Rather than have many preconceptions about what the machine would do, or it should look, we asked a lot of questions, and looked carefully at the settings in which the simulator would be used. The feedback from these interviews, and subsequent field test of prototypes fueled the internal company debate on design characteristics and product features. We used a modified software development strategy which allows for multiple iterations of input from a variety of sources. This process starts with concept creation and testing then proceeds to a story board or consensus model. Next we develop mockups or prototypes which allow us to interact with the model, and allow potential users to offer feedback on both simulation factors and human factors. Testing of these prototypes leads to pre-productions models where engineering constraints, software limitations, and timetables become more important.

At the same time, the researcengineering staff will assess the current state of the art in the technical and scientific areas which are relevant to the product. This review often produces new ideas, new capabilities, and new challenges for the development team.

The last stage is alpha and beta testing by future users. In developing the UltraSim® ultrasound simulator, we built and tested several successive generations of simulator prototypes and then ran extensive user testing with educators and students.

Key Points to consider:

Marketing

Concurrent with the product development activity, the marketing team should carry out a narrowly focused survey of the potential market for the simulator. This survey will identify future customers, and future users. These are not necessarily the same people. A simulator is purchased by the administration and directors of an ultrasound education program but the users will be teachers and students. The task for marketing is to understand the issues and features of the simulator which are important to both groups, their current teaching methods, and the potential for switching to a simulation assisted program. This assessment will produce a list of potentially conflicting demands and issues for each group. For example, the marketing assessment must include some investigation of the general or “ballpark” price for the simulator which would be acceptable to purchasers. This pricing consideration is essential to the development effort because of the constraints which it places on the budget, and the final configuration of the simulator. There is a normal conflict between engineering and marketing on the issue of price. The higher the price, the more comprehensive the product can be. With a lower price however, more units may be sold. The need to put quantitative assessments on these tradeoffs is essential, at the same time, good quantitative information can be very difficult to gather.

Meetings between these teams should be held early, and continue on an ongoing basis. The process often appears to be produce conflict. Conflict in the interaction between the marketing and engineering departments is not unusual and should not be suppressed. Marketing generally will argue for greater functionality, higher performance, more realism, and ease of use. While engineering will opt for more speed, simplicity, programming elegance, more shortcuts, and fewer features. The resolution of these debates, fueled by data gathering, can lead to successful incorporation of many features, in a timely and cost effective way. Look at the future implications of each decision in order to understand how it will affect the acceptance of the product in the market.

Key Points to Consider:

As the development effort progresses, the company enters a phase where operations and production become an important element of management responsibilities. Before the final prototype is accepted, a decision must be made where and how to produce the device. The development team may decide to embark on manufacturing themselves, or turn this task over to another company. Similarly, the marketing of the product may be much more involved and expensive than the developers are able to undertake. Under these circumstances, a strategic partner can be useful. Such a partner should have experience in the developing, manufacturing and sale of similar equipment. This experience can potentially save much time and money in realizing the goals of the development team and turning the product into a commercial success.

The same principal can be applied to other issues which arise as the company begins to add personnel, and expenses. Arranging for service and repair of the simulator after a unit is sold can be costly for a small company with relatively few products in the field. Flying a technician to a site is very expensive, and arranging for on-site service may disappoint the customer with poor quality. These issues and others should be researched and prepared for long before they become operational issues.
 

Organizational Development

The organizational type and implementation of the company or business unit has important implications for the eventual success of the simulator. What funds are available, how they are raised, what organizational form is adopted, and who are the key players in the development team can profoundly affect the success of your development effort. To some readers, this observation will seem obvious, to others it will not make any sense. Depending on an individual’s background and experiences, the design of a business may be as mysterious as physiology is to an MBA. A person inexperienced in business should seek and find help in addressing these issues. In addition to lawyers and accountants, an experienced business person, or two, can serve as a “kitchen cabinet.” This will help to ensure your success. The skills required to manage a technology development project, or to help a small company grow, are difficult to learn, and the individuals who have them are rare. Many will try, but few manage to persevere all the way to success.
 
 

Conclusion

At some point all of these decisions, analysis, and discussions must stop, and alternatives eliminated. It is not possible to create a simulator which is all things to all people. It is also not desirable to continue the development process forever. A product must be delivered to customers if this technology is going to be successful. The struggle to complete a simulator which addresses the needs of customers is a great challenge. Ity must also be manufactured on schedule, and be affordable. The solution of the problems discussed in this article can be accomplished. As the development team gains experience, using the experience of consultants and advisors, the product will take shape. The dividing line between realism and reality which lets us create educational simulators, must be tagand again in the search for a successful product. The final product is always a compromise between the goals and ideas of the team, the constraints of technology, and the reality of the marketplace.