Plug and Play Architectures for Rapid Development of Medical Simulation Manikins

Plug and Play Architectures for Rapid Development of Medical Simulation Manikins Peter Peters 1, Loe Feijs 1, and Guid Oei 2 1 Department of Industrial Design, Eindhoven University of Technology 5600 MB Eindhoven, The Netherlands p.j.f.peters@tue.nl, l.m.g.feijs@tue.nl 2 Máxima Medical Centre, 5500MB Veldhoven, The Netherlands s.g.oei@tue.nl ABSTRACT Medical simulation has become an accepted tool to support team training and quality assurance of medical interventions. Successful examples include paramedic emergency crew training, anesthesia and delivery training. In this article we work on the two hypotheses that (1) simulation will gradually be introduced in other medical areas as well, and (2) that the number of required functions and the level of required realism in a given application will steadily increase. This has farreaching technical consequences, notably a steep increase in technical complexity. We envisage specialized groups working on specific functions, specific pathologies, and/or selected interventions. The demand for managing this complexity asks for principles of open-source development. For the technical structure we translate the problem into the need for an open plug & play architecture. The article will discuss an exploration of three existing platforms originating from an intersection of the fields of embedded systems and design education. The focus of the work is on openness, which covers the nature of the plug and play mechanisms, scalability and extensibility. The three platforms are (1) Microchip PIC, (2) Lego NXT and (3) Phidgets MSP. As a case study we choose simple functions from the field of delivery and neonate simulations. Great-Britain more than 75% of newborns that had a bad start were exposed to suboptimal care [2]. Furthermore, medical interventions that are uncommon, or too low in frequency for regular real-life training, will have to be trained using non-reallife (i.e. simulated) training. A good example of the latter is breech delivery. After the publication of the term breech trial in The Netherlands 2000 it seemed to be accepted that when a child was in a breech position a cesarean section is better for the child. The number of cesarean sections in case of breech position rose from 50% to 80% within 2 months after this publication [9]. Even although there was negative criticism in the years thereafter, the percentage remained 80%. Keywords: Healthcare, Simulation, Team training, Plug and Play, Architecture, Hardware platforms, Open source. 1. MEDICAL SIMULATION RELEVANCE & TRENDS Simulation-based training has shown its merits in aerospace, the military, nuclear engineering and other professions where the real situation cannot be used to do training. The medical profession is a typical example where this frequently is the case as well. Although a lot of training of medical personnel can be done on the job, a vast number of medical interventions cannot be practiced on patients. In 2005 the Máxima Medical Centre (MMC) in Veldhoven, started simulation-based team trainings to train their multidisciplinary delivery teams, being the first hospital in The Netherlands to do so. As an example why the MMC started doing these trainings consider the following. Of all safety problems in hospitals, 65-70% is caused by human error [8]. Kohn et.al. describe that in the USA 98000 people die probably as a consequence of human error [6]. In Figure 1: Delivery simulation training session. As a consequence the number of natural breech deliveries decreased. Of the approximately 6000 breech deliveries per year in The Netherlands, around 20% is born naturally. Given the number of gynecologists, the final result being 1.4 natural breech deliveries per year per gynecologist, which is of course not enough to stay well trained for this specific intervention. Since breech delivery is only one of the many examples where lack of training applies, simulation-based training using appropriately designed manikins is a good way to get additional training (see figure 1). Currently, the MMC is starting a simulation centre (headed by the 3 rd author) where teams of medical personnel can be trained for specific situations. The environment created will enable team members to practice the near actual experience of performing specific interventions, not only from the purely medical point of view, but also evaluating communication and cooperation within the multidisciplinary

intervention teams. A complete environment that simulates the total experience is a major condition for the success of these trainings. 2. SYSTEM OVERVIEW A manikin is only one of the elements of the complete system used for training. There will be several other elements (virtual and/or physical) in the system; an important one of them will be a training scripting engine, controlling what actions should take place when, and how the manikin reacts upon these actions. This engine determines the scenario of the actual intervention practiced, what sensors are of importance in the scenario and how the manikin reacts on the actions performed during the training. The information exchange between the system elements will be done by message communication. Since the protocol used for message communication should not limit future extensions it is important to consider this protocol in an early stage of the system development. An over simplified depiction of the system is shown in figure 2. The system shows three possible system elements communicating: a training scripting engine, a manikin and a video detection and augmentation system. The communication between these elements will not consist of raw sensor data messages but of messages on a higher semantic level (e.g. change heart rate to 100 bpm, display face312 at position x, y ). Figure 2: System elements and communication The remainder of this paper focuses on possibilities for the softand hardware architectures needed to create the manikins used in these simulation-based trainings. 3. OPENNESS, ARCHITECTURE AND PLUG & PLAY 3.1 Openness Manikin Training Scripting Engine Video Detection & Augmentation Current state-of-the-art medical simulation manikins are proprietary designs (hardware, software and body), usually only available for usage and not available for exploration. Although these manikins cater for a need very well, they do not allow for third party alterations or extensions. Any changes and/or additions have to be implemented by the manufacturer and although they do a very good job, the development interests of the manufacturer are not necessarily the same as those of the user. The plug and play architecture proposed here is meant to enable development and extension of medical simulators by interested parties. The way this is enabled is by adhering to the Open Source Initiative (OSI). We assume that the principles of open design, amongst others applied in free software and opensource software [5], are re-usable in the medical simulation manikin context as well. Allowing free copy and redistribution of open source designs, accessibility of open source designs and redistribution of modified open source designs can result in a potentially large amount of developers and support, in the end leading to lower prices, faster development and opportunities for third parties to engage in production and commercial exploitation of service and support. Good examples of how this can lead to success is the Linux operating system [1] and many other open source software projects. The effects of adhering to the open design paradigm will however not be without consequence for the design of the manikin s architecture. To support ease of change, redistribution and copying, it is advisable to use modular design in most disciplines involved. This approach aims to subdivide a system into smaller parts (modules) that can be independently developed, manufactured, and used in different systems to drive multiple functionalities. It organizes a complex system as a set of distinct components that can be developed or modified independently and then plugged together. Although this may appear to be a simple idea, experience shows that the effectiveness of the technique depends critically on the way systems are divided into components and the mechanisms used to plug components together. 3.2 Architecture Two important obvious system elements that can be distinguished in the manikins are: hardware and software. For each of these elements early considerations for system architectures are necessary to prevent that the complexity of the system will in a later stage lead to the need for a complete redesign. Requirements that can be though of are: Scalability: Manikins will be equipped with a multitude of sensors and actuators, each of them requiring individual data transport. Although the early systems will start with a few sensors and actuators, the amount will quickly grow. Expandability: The wish to enable open design, not being able to foresee all developments, requires that the systems are expandable. It should be possible to add sensors and actuators not yet foreseen or not even existing yet. Cost: A well thought of architecture reduces development cost. Decisions like clustering of sensors around one controller or giving each sensor its own; choosing the right data transport mechanisms; Transmission media, buses, are of major importance. Lifetime/energy efficiency: Future manikins must be wireless. The manikin has to operate stand-alone for at least the amount of time a simulation will take. This constraints the power consumption of the electronics of the manikin. A well designed hard/software architecture will help to reduce power consumption. Quality: The collected information has to be sufficiently accurate and delivery of the information should be in time. Time relations between events must be preserved when translating them to event messages and delivering these. The way to realize these requirements is to define clear software and hardware interfaces that do not pose unnecessary limitations on the actual implementation but also do not allow unnecessary freedom. Things to consider are e.g. standardization of sensor/actuator values and definition of a transmission protocol that supports the above requirements. 3.3 Plug & play Plug & play refers to a set of requirements and technical mechanisms, roughly speaking the wish that a user can add a

new piece of hardware and start using it with a minimum of extra work such as installing software (preferably even without any work). In order to have a framework for evaluation and comparison we introduce some terminology and make a few assumptions. We assume that the system has a layered structure, much like the layers of the ISO Open Systems Interconnection Basic Reference Model [11] or an operating system. We assume Layer 1 to be the physical layer (hardware) and we assume one or more higher layers. Within each layer communication and resource management take place. Between the layers services are delivered. Layer N+1 requests services from layer N. We consider what happens when a new entity is added to layer N (see figure 3). service communication (new entity) Figure 3: Plug and Play layers Layer N+1 Layer N For example in the lowest layer, that is N=1, when new hardware is plugged into a socket physically (for N>1 a new entity means new software). The tasks of a Plug & play architecture in layer N are twofold: (T 1 ) to recognize inside layer N any newly added entity and enter it into the resource administration of layer N; resources comprise physical slots, timeslots, logical addresses, interrupt vectors, memory locations, or queues. (T 2 ) to make the entities of layer N+1 aware of the new services in layer N and allow them to use these services; the mechanisms to invoke services are for example event notification, method calls, (software) object creation. Service calls range from sending and receiving data packets to actions such as taking measurement values, emitting sounds or images, activating motors. Roughly speaking, the first task is about "plug", the second about "play". Typically T 1 is done by an operating system kernel or a bus manager. T 2 can be performed by a registry mechanism or a service broker. The challenge is that changes are propagated upward through multiple layers. In practice there may be several kinds of users, ranging from non-technical end-users (doctors and nurses), and service-personnel (course developers, calibration technicians) to technical developers who want to design an addition to an existing manikin. The plug & play issues should be discussed for each kind of user separately. Let us assume that the identified user makes the first step by adding a new entity in Layer N. For example, in Layer 1, the user adds a new sensor by plugging it in physically. Ideally everything else happens automatically and instantaneously. Things are not always ideal, however. Therefore, for each of the tasks T 1 and T 2 and for each kind of user the rest of the procedure is either manual or automated. It is also possible to have a mixed form (mixed means that for a application total of n steps in the procedure k steps are manual and n-k steps are automated). At the same time, as an orthogonal distinction, the procedure is either hot (no recompilation or restart is necessary) or cold (otherwise). Analyzing a given architecture for, say Layer 1, the summary could be for example: End user Technical developer T 1 auto hot manual T 2 auto cold manual cold cold Let's assume this example is about adding an extra loudspeaker. If the end user plugs it in, it is connected immediately and will not cause any malfunction of a first, already functioning, loudspeaker and its amplifier. The new loudspeaker even makes sound immediately, although perhaps it is just mono. The higher layer discovers the extra loudspeaker by itself, that is, the user need not tell the media-player that there is a second speaker. But in order to get stereo sound (fully exploit the extra service), the system needs to restart first (be switched on and off). For the technical developer the extension from a one-loudspeaker system to an n-loudspeaker system is significant extra work (for stereo + rear sound etc.) The procedures for the "end user" and "technical developer" do not coincide; the technical developer has to do extra work in order to make the ease-of-use for the end user happen later. Conversely, the developer's life is easier if certain problems can be left for the end user. 4. TECHNOLOGY EVALUATION FRAMEWORK 4.1 Evaluation framework To enable evaluation of the three platforms mentioned before we will pick two tasks to implement in each platform. The tasks will be implemented as crude prototypes, focusing on realization and functionality, not on outer appearance. The functionality of both prototypes we chose from the field of perinatology [3]. Rotation The first simulator prototype measures the rotation of the unborn child. This information is important for gynecologists when training for e.g. the maneuvers of van Deventer and Mariceau, used in breech deliveries [10]. The simulator mechanics will allow for the baby s rotation and a two-axis tilt sensor will be used to measure the rotation. Movement and flow The second prototype simulates the chest movements of a neonate child. These chest movements are caused by the air flow in and out of the lungs by natural or artificial respiration (e.g. applied using a bag valve mask). The chest movement (rhythm as well as excursion) is an important visual clue for the medical staff. A servo motor moving the chest up and down can be used to simulate the breathing movements. An air flow sensor can detect the air flow in the trachea caused by artificial respiration. The remainder of this paper will address the work done to research platforms that are usable in the development of manikin functionalities along the timeline spanning from rapid

prototyping to actual embedding of sensors and actuators in a production manikin. 4.2 Microchip microcontroller The Microchip PIC microcontroller platform used is based on a generic, proprietary developed circuit board containing an 8 bit Microchip microcontroller (PIC 18F4550). This platform is used to see what actual implementation effort it takes to create an embedded system using dedicated sensors and controlling them by software using this PIC board. Of the three platforms this platform is probably closest to the hardware/software platform that finally will be used to actually produce a manikin. Development of the software running on the microcontroller is done using the MPLAB IDE and the MPLAB C18 Compiler. The PIC board as we designed and use it provides 8 analog inputs, 8 digital outputs and 8 digital inputs (it allows for other configurations, but this was chosen to have a fair comparison to the Phidgets and LEGO platforms). The software runs an infinite loop measuring all sensors, calculating the mean value of 10 measurements per sensor on the fly and, encoding these sensor input values to values between 0 and 1024. These values are then communicated to the outside world using the RS232 serial protocol. Actuator values (using the same protocol) are decoded and put onto the output ports. It is easy to either use a standardized serial port via USB or to opt for wireless communication via ZigBee modules (MaxStream XBEE ). The end result will be that a communication channel exists between the prototype and a PC for exchanging sensor and actuator values. Processing these values can be done on the PC which is a more powerful platform. For many sensors finally needed in the manikins, custom development will be necessary. The hardware used for the prototypes is custom developed as well but is not very complex and uses commonly available electronic components. Using available Phidgets sensors (see section 4.4) is possible too, if the electronic interface of these sensors is adhered to. The rotation of the child inside the mother s womb in the first prototype is measured using an acceleration sensor. This sensor also measures inclination and therefore the child s rotation. The chest excursions in the second prototype can be induced by a servo motor that moves the chest area up and down. Airflow in the neonate s trachea is measured by an air flow sensor. Figure 4: PIC platform hardware The PIC platform used has its limitations in processing power, number of sensors and actuators that can be controlled and in choice of transmission possibilities. Newly available (and more powerful) PIC processors have been developed since, allowing for more options, but any solution chosen will have its limitations. Since the manikin development will gradually lead to a multitude of sensors and actuators, a solution for using multiple PIC boards, connecting them, and transmission of all sensors and actuators data has to be found. Figure 4 shows the PIC platform s hardware before it was built into the actual prototype. The baby background serves as a size reference; the actual size of the baby is 48 cm. 4.3 Lego Mindstorms NXT The LEGO Mindstorms Robotic Kit is a platform consisting of Lego Technic mechanical components, sensors, actuators, and a central microprocessor called NXT. An earlier version had a simpler controller called RCX, but here we shall focus on the latest version, the NXT. The system is interesting for two reasons: first, it has been designed with the goal of rapid and creative design for people of all ages and without high levels of technical training; secondly there is a growing awareness inside the LEGO community and even the company how open development processes can benefit all parties. Figure 5: LEGO platform hardware. The NXT contains an 32-bit ARM7 microcontroller with 256 Kbytes FLASH, 64 Kbytes RAM, an extra 8-bit AVR microcontroller with 4 Kbytes FLASH, 512 Byte RAM, Bluetooth wireless communication and a fast USB port. The control brick offers 4 input ports and 3 output ports. The processor as such is not extremely interesting, what is interesting however is the collection of robust sensors and actuators that comes along with it: a contact sensor (i.e. switch), a sound sensor, a light sensor, a distance sensor, and rotary sensors (inside servo motors). Many extra sensors are available through a kind of aftermarket or can be constructed according to easily accessible technical construction plans, see e.g. www.philohome.com/nxt.htm and the book Extreme NXT by Gasperi, Hurbain and Hurbain [7]. The connectors follow a 6- wire standard developed by LEGO (although not plug compatible with the old RCX there are some solutions to use the old two-wire sensors with the new brick). The control brick comes with a built-in power source of six AA batteries, which can be replaced by a rechargeable battery-pack. The NXT can be programmed in a variety of languages, including a brick-like flow chart language and Java (Lejos virtual machine). We experimented mostly with Java, since that is generally considered to be a reliable and future proof solution. It is particularly elegant to set-up the Bluetooth connection in Java and run both inside the NXT and on a host PC parallel Java programs which work together. The big disadvantage of the platform is the limitation to four outputs and three inputs. This is not enough except for the simplest robotic applications. Although in principle it should be possible to multiplex many sensors over a single NXT port using the I2C bus protocol, this

is not (yet) supported by the Java/Lejos software. In other words, one can solve these multiplexing problems, but this means serious engineering. Figure 5 shows the LEGO hardware with a baby background as size reference. 4.4 Phidgets The Phidgets interface platform produced by Phidgets Inc. consists of an easy to use set of building blocks for low cost sensing and control using a PC. The platform allows applications on the PC to be programmed in several programming languages like Java, C++, Delphi or Max/MSP using an easy application programming interface that connects to the (free) software that comes with the interface boards (API). A multitude of sensors and actuators are pre-produced on a small interface board, easily connectable using a flat-cable to a small main board that takes care of actually reading the sensors and transferring the information to the a USB bus interface. The language chosen for the Phidgets evaluation in this context is Max/MSP, a graphical programming language by Cycling 74, which allows for fast and easy visual programming. The Phidgets elements used for the prototype are a Phidgets Interfacekit 8/8/8, the main interface board giving 8 digital inputs, 8 digital outputs and 8 analog inputs, furthermore a Phidgets accelerometer, a Phidgets servo and, although this platform has a lot of different sensors available, building the prototype forced us to develop a custom sensor for measuring air flow that adheres to the Phidgets analog input specifications. The rotation of the child inside the mother s womb in the first prototype is measured using the Phidgets two-axis Accelerometer. The accelerometer also allows for inclination measurement and therefore for measurement of the child s rotation. The chest excursions in the second prototype can be induced by the Phidgets servo controller that controls a servo motor moving the chest area up and down. Measuring the airflow in the neonate s trachea is measured by the custom developed flow sensor. Figure 6 shows the Phidgets platform s hardware with a baby background as size reference. Figure 6: Phidgets platform hardware. 5. GIVING EACH TECHNOLOGY ITS PROPER PLACE Considering the conflicting requirements of easy experimentation on the one hand, and efficiency and miniaturization on the other hand, it is not obvious how to choose from the various technologies described in Section 4. Therefore we propose to allocate each technology type to a specific phase of the development of manikins. The situation is illustrated by figure 7: three different situations, for the time being called concept training room, development training room, and production training room. In each situation some experimental training takes place. The first situation is about idea and concept generation, where innovative practices from the medical profession are to be translated into training concepts, therefore this is called the concept training room. The second situation is about detailing the concept and combining it with other simulation components. This is much more demanding in terms of technical support and we call this the development training room, that is, the training room where technical development takes place. The third situation is called production training room. The term production refers both to the manikins, which are probably produced in larger quantities, and to the training rooms, whose purpose is to train medical personnel in a cost-efficient way, not further development. The three situations correspond to a decreasing need for rapid prototyping and development and an increasing need for technical sophistication, efficiency of the hardware, reliability and miniaturization. Figure 7: Technology mapping to development / usage stage. Whereas in the concept training room even the doctors and the innovators in the medical field can bring a new concept alive using LEGO Mindstorms without professional technical support, the development training room is populated by a mix of medical specialists and technical people. This is where a graphical programming language such as Max/MSP and the easily pluggable Phidgets are very attractive. In the production training room there should be no developers. But there is a new role: the trainer, who wants to reuse his or her didactic experiences and cast them into scripts or high-level descriptions of scenarios. This is where the software will fall apart into several types of software: embedded components, close to the hardware, such as C programs for PICs; and on the other hand high level scripts or scenario's. Architectures such as described by [4] will be of help to put the two together. We ought to say something about the transformation of the concepts and artifacts from one training room to the next. When going from the concept to the development, only the concept is transferred, but neither the software nor the hardware embodiment. The transformation from development to production is more complex, and actually is an area where a lot of work still has to be done. The following considerations apply: In an implementation using a graphical programming language such as Max/MSP, all software runs as one graphically designed program on a centralized PC. In these programs the scenarios and ordering of training events are coded, but also the feedback loops governing local sensor-

actuator behaviors such as temperature control, and simulations of reflexes. In a final implementation it is much better to split the software into independent parts. The scripting of scenarios is to be done using a high-level language whose execution takes place on a PC. The local control loops can run more efficiently, reliably and autonomous when embedded on a PIC and written in a system language such as C. The transition from development to production needs to be as smooth as possible. An important step has already been taken by us: we have established hardware-level compatibility between Phidgets and PIC by designing the hardware such that the very same sensors and actuators that plug into the Phidgets main board, now also can be plugged into the PIC. The transition from development to production will also have an effect on the way the sensor and actuator data are communicated (figure 8). In concept stage, LEGO, PIC and/or Phidgets and their sensors will communicate the sensor/actuator data directly to a PC where the actual processing of the data is done and also the prototype s functionality is defined. Sensor PC Lego Lego PC Phidgets Phidgets Phidgets Figure 8: Concept Development Production trajectory. In the development stage some sensor data processing will take place in the local platform, but still the PC as a backup processing system will be necessary. In this stage the PC could already fulfill the task of a limited scripting engine as well. In the production stage most of the sensor/actuator processing is located in the manikin s hardware. The PC will then serve as scripting engine, interpreting messages on a semantic level. 6. CONCLUSIONS Creating the prototypes taught us that using the LEGO and Phidgets interface elements allows for faster initial development than the PIC platform. The PIC platform here is representative for a wide class of similar platforms. Although the PIC platform is more difficult to start with, since the interfacing that comes for free with Phidgets and LEGO has to be developed by the user, once the effort of starting up has been invested, the major differences in using the platforms come from size, speed, sensor availability and flexibility. The PIC platform has highest flexibility in changing virtually all system hardware requirements but also e.g. in choosing communication protocols and transmission media. Using Phidgets and LEGO is much PC Pic Pic Pi more rigid in that aspect. Looking at future developments, the flexibility of the PIC platform (or something similar) that will allow this free choice might be of crucial importance. We claim that we have made already a significant contribution to a smooth transition between the PIC and Phidgets platforms. Yet, more work is needed. We mention two important options. First, to build in plug & play mechanisms as outlined in sect. 3.3. Secondly to develop tools to automate the transition from the prototyping language in use to the actual embedded platform. 7. REFERENCES [[1] J. Dinkelacker, P. K. Garg, R. Miller and D. Nelson, Progressive open source, Proceedings of the 24th International Conference on Software Engineering, ACM Press, Orlando, Florida, 2002. [2] T. Draycott, T. Sibanda, L. Owen, V. Akande, C. Winter, S. Reading and A. Whitelaw, Does training in obstetric emergencies improve neonatal outcome, 2006, pp. 177-82. [3] K. Grady, Howell, C., Cox, C., Managing Obstetric Emergencies and Trauma, RCOG Press, London, 2002. [4] J. Hu, Design of a distributed architecture for enriching media experience in home theaters, PhD. Thesis TU/e (2006). [5] J. Johnson-Eilola, Open source basics: definitions, models, and questions, Proceedings of the 20th annual international conference on Computer documentation, ACM Press, Toronto, Ontario, Canada, 2002. [6] L. T. Kohn, J. Corrigan and M. S. Donaldson, To Err Is Human: Building a Safer Health System, National Academy Press, 2000. [7] G. Michael, E. H. Philippe and L. H. Isabelle, Extreme NXT: Extending the LEGO Mindstorms NXT to the Next Level, Apress, 2007. [8] L. Pizzi and P. Goldfarb, Crew Resource Management and its Applications in Medicine, in K. G. Shojania, Duncan, B.W., McDonald, K.M., Wachter, R.M., ed., Making health care safer, a critical analysis of patient safety practices., Rockville, 2001, pp. 501-510. [9] C. C. T. Rietberg, P. M. Elferink-Stinkens and G. H. A. Visser, The effect of the Term Breech Trial on medical intervention behaviour and neonatal outcome in The Netherland: an analysis of 35 453 term breech infants, Blackwell Synergy, 2005, pp. 205-209. [10] Voss B., Feijs L. and O. S., Een interactief foetusmodel voor de simulatie van stuitbevallingen, Medisch Journaal (2006), pp. 124-125. [11] H. Zimmermann, OSI Reference Model--The ISO Model of Architecture for Open Systems Interconnection, IEEE Transactions on Communications, 28 (1980), pp. 425-432.