Plug and Play Architectures for Rapid Development of Medical Simulation Manikins

Peter Peters 1, Loe Feijs 1, and Guid Oei 2 1Department of Industrial Design, Eindhoven University of Technology 5600 MB Eindhoven, The Netherlands [email protected], [email protected] 2Máxima Medical Centre, 5500MB Veldhoven, The Netherlands [email protected]

ABSTRACT Great-Britain more than 75% of newborns that had a bad start Medical simulation has become an accepted tool to support were exposed to suboptimal care [2]. Furthermore, medical team training and quality assurance of medical interventions. interventions that are uncommon, or too low in frequency for Successful examples include paramedic emergency crew regular real-life training, will have to be trained using non-real- training, anesthesia and delivery training. In this article we work life (i.e. simulated) training. A good example of the latter is on the two hypotheses that (1) simulation will gradually be breech delivery. After the publication of the ‘term breech trial’ introduced in other medical areas as well, and (2) that the in The Netherlands 2000 it seemed to be accepted that when a number of required functions and the level of required realism child was in a breech position a cesarean section is better for the in a given application will steadily increase. This has far- child. The number of cesarean sections in case of breech reaching technical consequences, notably a steep increase in position rose from 50% to 80% within 2 months after this technical complexity. We envisage specialized groups working publication [9]. Even although there was negative criticism in on specific functions, specific pathologies, and/or selected the years thereafter, the percentage remained 80%. 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. Keywords: Healthcare, Simulation, Team training, Plug and Play, Architecture, Hardware platforms, Open source.

Figure 1: Delivery simulation training session . 1. MEDICAL SIMULATION RELEVANCE & TRENDS As a consequence the number of natural breech deliveries decreased. Of the approximately 6000 breech deliveries per year Simulation-based training has shown its merits in aerospace, the in The Netherlands, around 20% is born naturally. Given the military, nuclear engineering and other professions where the number of gynecologists, the final result being 1.4 natural real situation cannot be used to do training. The medical breech deliveries per year per gynecologist, which is of course profession is a typical example where this frequently is the case not enough to stay well trained for this specific intervention. as well. Although a lot of training of medical personnel can be Since breech delivery is only one of the many examples where done ‘on the job’, a vast number of medical interventions lack of training applies, simulation-based training using cannot be practiced on patients. In 2005 the Máxima Medical appropriately designed manikins is a good way to get additional Centre (MMC) in Veldhoven, started simulation-based team training (see figure 1). Currently, the MMC is starting a trainings to train their multidisciplinary delivery teams, being simulation centre (headed by the 3 rd author) where teams of the first hospital in The Netherlands to do so. As an example medical personnel can be trained for specific situations. The why the MMC started doing these trainings consider the environment created will enable team members to practice the following. Of all safety problems in hospitals, 65-70% is caused near actual experience of performing specific interventions, not by human error [8]. Kohn et.al. describe that in the USA 98000 only from the purely medical point of view, but also evaluating people die probably as a consequence of human error [6]. In communication and cooperation within the multidisciplinary intervention teams. A complete environment that simulates the redistribution of modified open source designs can result in a total experience is a major condition for the success of these potentially large amount of developers and support, in the end trainings. leading to lower prices, faster development and opportunities 2. SYSTEM OVERVIEW for third parties to engage in production and commercial exploitation of service and support. Good examples of how this A manikin is only one of the elements of the complete system can lead to success is the Linux operating system [1] and many used for training. There will be several other elements (virtual other open source software projects. The effects of adhering to and/or physical) in the system; an important one of them will be the open design paradigm will however not be without a training scripting engine, controlling what actions should take consequence for the design of the manikin’s architecture. To place when, and how the manikin reacts upon these actions. support ease of change, redistribution and copying, it is This engine determines the scenario of the actual intervention advisable to use modular design in most disciplines involved. practiced, what sensors are of importance in the scenario and This approach aims to subdivide a system into smaller parts how the manikin reacts on the actions performed during the (modules) that can be independently developed, manufactured, training. The information exchange between the system and used in different systems to drive multiple functionalities. It elements will be done by message communication. Since the organizes a complex system as a set of distinct components that protocol used for message communication should not limit can be developed –or modified– independently and then future extensions it is important to consider this protocol in an plugged together. Although this may appear to be a simple idea, early stage of the system development. An over simplified experience shows that the effectiveness of the technique depiction of the system is shown in figure 2. The system shows depends critically on the way systems are divided into three possible system elements communicating: a training components and the mechanisms used to plug components scripting engine, a manikin and a video detection and together. 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 3.2 Architecture 100 bpm”, “display face312 at position x, y”). 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 Training system will in a later stage lead to the need for a complete Scripting redesign. Requirements that can be though of are: Engine • 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. • Video Expandability: The wish to enable open design, not being Manikin Detection & able to foresee all developments, requires that the systems Augmentation 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 Figure 2: System elements and communication cost. Decisions like clustering of sensors around one The remainder of this paper focuses on possibilities for the soft- controller or giving each sensor its own; choosing the right and hardware architectures needed to create the manikins used data transport mechanisms; Transmission media, buses, are in these simulation-based trainings. of major importance. • Lifetime/energy efficiency: Future manikins must be wireless. The manikin has to operate stand-alone for at 3. OPENNESS, ARCHITECTURE AND PLUG & PLAY least the amount of time a simulation will take. This constraints the power consumption of the electronics of the 3.1 Openness manikin. A well designed hard/software architecture will Current state-of-the-art medical simulation manikins are help to reduce power consumption. proprietary designs (hardware, software and body), usually only • Quality: The collected information has to be sufficiently available for usage and not available for exploration. Although accurate and delivery of the information should be in time. these manikins cater for a need very well, they do not allow for Time relations between events must be preserved when third party alterations or extensions. Any changes and/or translating them to event messages and delivering these. additions have to be implemented by the manufacturer and although they do a very good job, the development interests of The way to realize these requirements is to define clear software the manufacturer are not necessarily the same as those of the and hardware interfaces that do not pose unnecessary limitations user. The plug and play architecture proposed here is meant to on the actual implementation but also do not allow unnecessary enable development and extension of medical simulators by freedom. Things to consider are e.g. standardization of interested parties. The way this is enabled is by adhering to the sensor/actuator values and definition of a transmission protocol Open Source Initiative (OSI). We assume that the principles of that supports the above requirements. open design, amongst others applied in free software and open- source software [5], are re-usable in the medical simulation 3.3 Plug & play manikin context as well. Allowing free copy and redistribution Plug & play refers to a set of requirements and technical of open source designs, accessibility of open source designs and mechanisms, roughly speaking the wish that a user can add a new piece of hardware and start using it with a minimum of total of n steps in the procedure k steps are manual and n-k steps extra work such as installing software (preferably even without are automated). At the same time, as an orthogonal distinction, any work). In order to have a framework for evaluation and the procedure is either hot (no recompilation or restart is comparison we introduce some terminology and make a few necessary) or cold (otherwise). assumptions. Analyzing a given architecture for, say Layer 1, the summary We assume that the system has a layered structure, could be for example: 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 End user Technical developer or more higher layers. Within each layer communication and T auto hot manual cold resource management take place. Between the layers services 1 are delivered. Layer N+1 requests services from layer N. We T2 auto cold manual cold consider what happens when a new entity is added to layer N (see figure 3). Let's assume this example is about adding an extra loudspeaker. communication 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 Layer N+1 sound immediately, although perhaps it is just mono. The higher application

service 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 (new entity) Layer N system to an n-loudspeaker system is significant extra work (for stereo + rear sound etc.) The procedures for the "end user" and "technical Figure 3: Plug and Play layers developer" do not coincide; the technical developer has to do For example in the lowest layer, that is N=1, when new extra work in order to make the ease-of-use for the end user hardware is plugged into a socket physically (for N>1 a new happen later. Conversely, the developer's life is easier if certain entity means new software). The tasks of a Plug & play problems can be left for the end user. architecture in layer N are twofold: • (T 1) to recognize inside layer N any newly added entity 4. TECHNOLOGY EVALUATION FRAMEWORK and enter it into the resource administration of layer N; 4.1 Evaluation framework resources comprise physical slots, timeslots, logical addresses, interrupt vectors, memory locations, or queues. To enable evaluation of the three platforms mentioned before • (T 2) to make the entities of layer N+1 aware of the new we will pick two tasks to implement in each platform. The tasks services in layer N and allow them to use these services; will be implemented as crude prototypes, focusing on the mechanisms to invoke services are for example event realization and functionality, not on outer appearance. The notification, method calls, (software) object creation. functionality of both prototypes we chose from the field of Service calls range from sending and receiving data perinatology [3]. packets to actions such as taking measurement values, Rotation emitting sounds or images, activating motors. The first simulator prototype measures the rotation of the unborn child. This information is important for gynecologists Roughly speaking, the first task is about "plug", the second when training for e.g. the maneuvers of van Deventer and about "play". Typically T 1 is done by an operating system kernel Mariceau, used in breech deliveries [10]. The simulator or a bus manager. T 2 can be performed by a registry mechanism mechanics will allow for the baby’s rotation and a two-axis tilt or a service broker. The challenge is that changes are sensor will be used to measure the rotation. propagated upward through multiple layers. Movement and flow In practice there may be several kinds of users, ranging from non-technical end-users (doctors and nurses), and The second prototype simulates the chest movements of a service-personnel (course developers, calibration technicians) to neonate child. These chest movements are caused by the air technical developers who want to design an addition to an flow in and out of the lungs by natural or artificial respiration existing manikin. The plug & play issues should be discussed (e.g. applied using a bag valve mask). The chest movement for each kind of user separately. (rhythm as well as excursion) is an important visual clue for the medical staff. A servo motor moving the chest up and down can Let us assume that the identified user makes the first be used to simulate the breathing movements. An air flow step by adding a new entity in Layer N. For example, in Layer sensor can detect the air flow in the trachea caused by artificial 1, the user adds a new sensor by plugging it in physically. respiration. Ideally everything else happens automatically and instantaneously. Things are not always ideal, however. The remainder of this paper will address the work done to research platforms that are usable in the development of 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 manikin functionalities along the timeline spanning from rapid is also possible to have a mixed form (mixed means that for a prototyping to actual embedding of sensors and actuators in a multiple PIC boards, connecting them, and transmission of all ‘production’ manikin. 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 4.2 Microchip microcontroller actual size of the baby is 48 cm. ® 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 4.3 Lego Mindstorms NXT used to see what actual implementation effort it takes to create The LEGO® Mindstorms Robotic Kit is a platform consisting an embedded system using dedicated sensors and controlling of Lego Technic mechanical components, sensors, actuators, them by software using this PIC board. Of the three platforms and a central microprocessor called NXT. An earlier version this platform is probably closest to the hardware/software had a simpler controller called RCX, but here we shall focus on platform that finally will be used to actually produce a manikin. the latest version, the NXT. The system is interesting for two Development of the software running on the microcontroller is reasons: first, it has been designed with the goal of rapid and done using the MPLAB ® IDE and the MPLAB ® C18 Compiler. creative design for people of all ages and without high levels of The PIC board as we designed and use it provides 8 analog technical training; secondly there is a growing awareness inside inputs, 8 digital outputs and 8 digital inputs (it allows for other the LEGO community and even the company how open configurations, but this was chosen to have a fair comparison to development processes can benefit all parties. 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 Figure 5: LEGO platform hardware. electronic components. Using available Phidgets sensors (see section 4.4) is possible too, if the electronic interface of these The NXT contains an 32-bit ARM7 microcontroller with 256 sensors is adhered to. The rotation of the child inside the Kbytes FLASH, 64 Kbytes RAM, an extra 8-bit AVR mother’s womb in the first prototype is measured using an microcontroller with 4 Kbytes FLASH, 512 Byte RAM, acceleration sensor. This sensor also measures inclination and Bluetooth wireless communication and a fast USB port. The therefore the child’s rotation. The chest excursions in the second control brick offers 4 input ports and 3 output ports. The prototype can be induced by a servo motor that moves the chest processor as such is not extremely interesting, what is area up and down. Airflow in the neonate’s trachea is measured interesting however is the collection of robust sensors and by an air flow sensor. 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 Figure 4: PIC platform hardware considered to be a reliable and future proof solution. It is The PIC platform used has its limitations in processing power, particularly elegant to set-up the Bluetooth connection in Java number of sensors and actuators that can be controlled and in and run both inside the NXT and on a host PC parallel Java choice of transmission possibilities. Newly available (and more programs which work together. The big disadvantage of the powerful) PIC processors have been developed since, allowing platform is the limitation to four outputs and three inputs. This for more options, but any solution chosen will have its is not enough except for the simplest robotic applications. limitations. Since the manikin development will gradually lead Although in principle it should be possible to multiplex many to a multitude of sensors and actuators, a solution for using sensors over a single NXT port using the I2C bus protocol, this is not (yet) supported by the Java/Lejos software. In other specific phase of the development of manikins. The situation is words, one can solve these multiplexing problems, but this illustrated by figure 7: three different situations, for the time means serious engineering. Figure 5 shows the LEGO hardware being called concept training room , development training room , with a baby background as size reference. 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 4.4 Phidgets the medical profession are to be translated into training The Phidgets interface platform produced by Phidgets Inc. concepts, therefore this is called the concept training room . The consists of an easy to use set of building blocks for low cost second situation is about detailing the concept and combining it sensing and control using a PC. The platform allows with other simulation components. This is much more applications on the PC to be programmed in several demanding in terms of technical support and we call this the programming languages like Java, C++, Delphi or Max/MSP development training room , that is, the training room where using an easy application programming interface that connects technical development takes place. The third situation is called to the (free) software that comes with the interface boards production training room . The term production refers both to (API). A multitude of sensors and actuators are pre-produced on the manikins, which are probably produced in larger quantities, a small interface board, easily connectable using a flat-cable to and to the training rooms, whose purpose is to train medical a small main board that takes care of actually reading the personnel in a cost-efficient way, not further development. The sensors and transferring the information to the a USB bus three situations correspond to a decreasing need for rapid interface. The language chosen for the Phidgets evaluation in prototyping and development and an increasing need for this context is Max/MSP, a graphical programming language by technical sophistication, efficiency of the hardware, reliability Cycling ’74, which allows for fast and easy visual and miniaturization. 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 Figure 7: Technology mapping to development / usage stage. airflow in the neonate’s trachea is measured by the custom developed flow sensor. Figure 6 shows the Phidgets platform’s Whereas in the concept training room even the doctors and the hardware with a baby background as size reference. 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 Figure 6: Phidgets platform hardware. embodiment. The transformation from development to production is more complex, and actually is an area where a lot 5. GIVING EACH TECHNOLOGY ITS PROPER PLACE of work still has to be done. The following considerations apply: Considering the conflicting requirements of easy experimentation on the one hand, and efficiency and • In an implementation using a graphical programming miniaturization on the other hand, it is not obvious how to language such as Max/MSP, all software runs as one choose from the various technologies described in Section 4. graphically designed program on a centralized PC. In these Therefore we propose to allocate each technology type to a 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 more rigid in that aspect. Looking at future developments, the simulations of reflexes. flexibility of the PIC platform (or something similar) that will • In a final implementation it is much better to split the allow this free choice might be of crucial importance. We claim software into independent parts. The scripting of scenarios that we have made already a significant contribution to a is to be done using a high-level language whose execution smooth transition between the PIC and Phidgets platforms. Yet, takes place on a PC. The local control loops can run more more work is needed. We mention two important options. First, efficiently, reliably and autonomous when embedded on a to build in plug & play mechanisms as outlined in sect. 3.3. PIC and written in a system language such as C. Secondly to develop tools to automate the transition from the prototyping language in use to the actual embedded platform. 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 7. REFERENCES between Phidgets and PIC by designing the hardware such that the very same sensors and actuators that plug into the Phidgets [[1] J. Dinkelacker, P. K. Garg, R. Miller and D. Nelson, main board, now also can be plugged into the PIC. The Progressive open source , Proceedings of the 24th transition from development to production will also have an International Conference on Software Engineering , ACM effect on the way the sensor and actuator data are Press, Orlando, Florida, 2002. communicated (figure 8). In concept stage, LEGO, PIC and/or [2] T. Draycott, T. Sibanda, L. Owen, V. Akande, C. Winter, Phidgets and their sensors will communicate the sensor/actuator S. Reading and A. Whitelaw, Does training in obstetric data directly to a PC where the actual processing of the data is emergencies improve neonatal outcome , 2006, pp. 177-82. done and also the prototype’s functionality is defined. [3] K. Grady, Howell, C., Cox, C., Managing Obstetric Emergencies and Trauma , RCOG Press, London, 2002. PC PC PC [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, Phidgets Lego Pic and questions , Proceedings of the 20th annual Sensors Sensors Sensors Lego Phidgets Pic Sensors Sensors international conference on Computer documentation , Sensor Phidgets Pi Sensors ACM Press, Toronto, Ontario, Canada, 2002. Sensors [6] L. T. Kohn, J. Corrigan and M. S. Donaldson, To Err Is Figure 8: Concept – Development – Production trajectory. Human: Building a Safer Health System, National In the development stage some sensor data processing will take Academy Press, 2000. place in the local platform, but still the PC as a backup [7] G. Michael, E. H. Philippe and L. H. Isabelle, Extreme processing system will be necessary. In this stage the PC could NXT: Extending the LEGO Mindstorms NXT to the Next already fulfill the task of a limited scripting engine as well. In Level , Apress, 2007. the production stage most of the sensor/actuator processing is [8] L. Pizzi and P. Goldfarb, Crew Resource Management and located in the manikin’s hardware. The PC will then serve as its Applications in Medicine , in K. G. Shojania, Duncan, scripting engine, interpreting messages on a semantic level. 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. 6. CONCLUSIONS [9] C. C. T. Rietberg, P. M. Elferink-Stinkens and G. H. A. Creating the prototypes taught us that using the LEGO and Visser, The effect of the Term Breech Trial on medical Phidgets interface elements allows for faster initial development intervention behaviour and neonatal outcome in The than the PIC platform. The PIC platform here is representative Netherland: an analysis of 35 453 term breech infants , for a wide class of similar platforms. Although the PIC platform Blackwell Synergy, 2005, pp. 205-209. is more difficult to start with, since the interfacing that comes [10] Voss B., Feijs L. and O. S., Een interactief foetusmodel for free with Phidgets and LEGO has to be developed by the voor de simulatie van stuitbevallingen , Medisch Journaal user, once the effort of starting up has been invested, the major (2006), pp. 124-125. differences in using the platforms come from size, speed, sensor [11] H. Zimmermann, OSI Reference Model--The ISO Model of availability and flexibility. The PIC platform has highest Architecture for Open Systems Interconnection , IEEE flexibility in changing virtually all system hardware Transactions on Communications, 28 (1980), pp. 425-432. requirements but also e.g. in choosing communication protocols and transmission media. Using Phidgets and LEGO is much