The Advanced Modular Manikin Open Source Platform for Healthcare Simulation

Introduction: Current thinking in healthcare education stipulates a holistic approach with a focus on patient management, bringing together technical skills, decision-making, and team performance. In parallel, training opportunities with actual patients have diminished, and the number of different interventions to master has increased. Training on simulators has become broadly accepted; however, requirements for such training devices have outpaced the development of new simulators. The Department of Defense (DoD) targeted this gap with a development challenge. This article introduces the Advanced Modular Manikin (AMM) platform and describes the path followed to address the challenge. Materials and Methods: Under Contract # W81XWH-14-C-0101, our interdisciplinary team of healthcare providers, educators, engineers, and scientists, together with partners in industry and the government collaborated to establish a set of comprehensive requirements and develop an overarching system architecture and specifications to meet healthcare simulation needs. In order to instantiate the architecture and investigate usability of the platform, a demonstration modular manikin was created that incorporated physical and digital peripherals. Results: The system architecture and corresponding data models have been completed and published as open source. A developer’s tool kit has been created, including instructional materials and required hardware and software for interested parties to develop AMM-compatible modules. A reference manikin was created based on the platform specifications and successfully supported a usability study that was performed by the American College of Surgeons, Education Division at the Naval Medical Center San Diego. Conclusions: The formal release of a functional modular, interoperable open-source healthcare simulation platform is complete. Next steps involve a strategy for maintaining the open standards and verification of AMM-compatibility for modules. Increasing awareness of this powerful tool and prioritization of module-development to address the wide range of healthcare education needs could lead to a renaissance in military and civilian healthcare simulation-based training. BACKGROUND Military healthcare provider training has evolved from the traditional apprenticeship model to one based on the science of education. Training models such as simulators continue to evolve as important tools to help providers obtain and maintain core knowledge and skills.1–4 The development of many of today’s healthcare simulation systems derived from military contracts. As simulation companies have succeeded in *Department of Urology, University of Minnesota, MMC 394, Minneapolis, MN, 55455, USA †Department of Surgery, University of Washington, Seattle, WA, 98195, USA ‡Vcom3D, Orlando, FL, 32817, USA §Entropic Engineering, MN, 55114, USA ∥U.S. Army Combat Capabilities Development Command Soldier Center, Medical Simulation Research Branch, Orlando, FL, 32826-3276, USA #Undergraduate; No Degree Presented at the 2019 Military Health System Research Symposium, Kissimmee, FL; MHSRS-19-02647. doi:10.1093/milmed/usaa420 © The Association of Military Surgeons of the United States 2021. All rights reserved. For permissions, please e-mail: journals. permissions@oup.com. the market place, they have created their own closed ecosystems. Subsequently, industry has not been able to develop a business model or technical solution to address the breadth of military healthcare training needs. This is especially the case for “interventional and surgical” procedures.5,6 For example, almost none of the partial-task trainer systems contain a link to actual patient physiology. In addition, a majority of physical exam findings, diseases, conditions, pathologies, interventions, and scenarios seen in healthcare cannot be represented through simulated models with today’s legacy systems. To address the gap between needs and available training solutions, the Department of Defense (DoD) has shifted its emphasis in support of projects with an open-standards/opensourcemodel. TheAdvancedModularManikin (AMM) solicitation (#W81XWH-13-R-0032) sought to: “Advance the state of the art in medical simulation-based training. The system (should) be state of the art, modular, and relatively autonomous. It will serve as a core platform that allows scaling from a simple, to a vastly more capable unit, using future commercial upgrades, ‘peripherals’ that can be obtained from a variety of potential sources.”7 This resulted in an effort, directed by the Medical Simulation and Information Sciences MILITARY MEDICINE, Vol. 186, January/February Supplement 2021 49 D ow naded rom http/academ ic.p.com /m ilm ed/arti86/Supplem ent_1/6119491 by gest on 26 Jauary 2021 The Advanced Modular Manikin Platform Research Program, Joint Program Committee 1 (JPC-1) to establish the open standards for the system architecture and data models, design a universal connector, and publish a set of reference hardware designs and software modules as a developer’s tool kit. Developed under contract # W81XWH-14-C-0101, AMM is an open-source, interoperable platform that includes a first set (alpha) of male and female digital standard human anatomic models, a universal connector for air, fluid, power and data, a developer’s toolkit, and software libraries and standards. Deliverables were designed and developed with the intent of accelerating and advancing the applications for simulation in healthcare. The overall objective of this program was to create the formal release of AMM 1.0 as an opensource resource for the healthcare simulation community. The purpose of this article is to introduce the readers to the concept and structure of the AMM program and provide evidence of its functionality as an open-source, open-standards platform. METHODS The Center for Research in Education and Simulation Technologies (CREST) assembled an interdisciplinary team of healthcare providers, educators, engineers, scientists, together with partners in industry and the government to conceive and create AMM.8–10 We started with requirements— capture and design of the system architecture, developed guidelines, and developed and tested bench models of critical components to verify design decisions. Finally, we built a reference system physical manikin to demonstrate the feasibility of the integrated platform. Bench testing was performed on the hardware and software deliverables at the University of Minnesota, University of Washington and Vcom3D (Sarasota, FL). A preliminary pilot study was performed at the WWAMI Institute for Simulation in Healthcare at the University of Washington by a team led by the American College of Surgeons Division of Education (Chicago, IL), followed by a study performed at the Naval Hospital in San Diego. Capture and Verification of Requirements Focus groups, conference workshops, and site visits were utilized to query the training needs from a broad group of stake holders across both the military and civilian domains including educators, pre-hospital and hospital-based practitioners, members of industry and simulation technicians. The interviews were recorded and reviewed to identify unmet needs. The team also reviewed data generated from the literature with a focus on the University of Minnesota Combat Casualty TrainingConsortium’s evaluation of existing part-task trainers focused on basic hemorrhage control and airway management procedures (Contract # W81XWH-11-2-0185).11 System Architecture As work moved from requirements and specifications to development, we used a System of Systems Engineering approach to create a distributed, modular, interoperable, and scalable platform.12–19 We applied the concepts of decoupled complexity and distributed processing to allow for module independence.

the market place, they have created their own closed ecosystems. Subsequently, industry has not been able to develop a business model or technical solution to address the breadth of military healthcare training needs. This is especially the case for "interventional and surgical" procedures. 5,6 For example, almost none of the partial-task trainer systems contain a link to actual patient physiology. In addition, a majority of physical exam findings, diseases, conditions, pathologies, interventions, and scenarios seen in healthcare cannot be represented through simulated models with today's legacy systems.
To address the gap between needs and available training solutions, the Department of Defense (DoD) has shifted its emphasis in support of projects with an open-standards/opensource model. The Advanced Modular Manikin (AMM) solicitation (#W81XWH-13-R-0032) sought to: "Advance the state of the art in medical simulation-based training. The system (should) be state of the art, modular, and relatively autonomous. It will serve as a core platform that allows scaling from a simple, to a vastly more capable unit, using future commercial upgrades, 'peripherals' that can be obtained from a variety of potential sources." 7 This resulted in an effort, directed by the Medical Simulation and Information Sciences Research Program, Joint Program Committee 1 (JPC-1) to establish the open standards for the system architecture and data models, design a universal connector, and publish a set of reference hardware designs and software modules as a developer's tool kit.
Developed under contract # W81XWH-14-C-0101, AMM is an open-source, interoperable platform that includes a first set (alpha) of male and female digital standard human anatomic models, a universal connector for air, fluid, power and data, a developer's toolkit, and software libraries and standards. Deliverables were designed and developed with the intent of accelerating and advancing the applications for simulation in healthcare. The overall objective of this program was to create the formal release of AMM 1.0 as an opensource resource for the healthcare simulation community. The purpose of this article is to introduce the readers to the concept and structure of the AMM program and provide evidence of its functionality as an open-source, open-standards platform.

METHODS
The Center for Research in Education and Simulation Technologies (CREST) assembled an interdisciplinary team of healthcare providers, educators, engineers, scientists, together with partners in industry and the government to conceive and create AMM. [8][9][10] We started with requirementscapture and design of the system architecture, developed guidelines, and developed and tested bench models of critical components to verify design decisions. Finally, we built a reference system physical manikin to demonstrate the feasibility of the integrated platform. Bench testing was performed on the hardware and software deliverables at the University of Minnesota, University of Washington and Vcom3D (Sarasota, FL). A preliminary pilot study was performed at the WWAMI Institute for Simulation in Healthcare at the University of Washington by a team led by the American College of Surgeons Division of Education (Chicago, IL), followed by a study performed at the Naval Hospital in San Diego.

Capture and Verification of Requirements
Focus groups, conference workshops, and site visits were utilized to query the training needs from a broad group of stake holders across both the military and civilian domains including educators, pre-hospital and hospital-based practitioners, members of industry and simulation technicians. The interviews were recorded and reviewed to identify unmet needs. The team also reviewed data generated from the literature with a focus on the University of Minnesota Combat Casualty Training Consortium's evaluation of existing part-task trainers focused on basic hemorrhage control and airway management procedures (Contract # W81XWH-11-2-0185). 11

System Architecture
As work moved from requirements and specifications to development, we used a System of Systems Engineering approach to create a distributed, modular, interoperable, and scalable platform. [12][13][14][15][16][17][18][19] We applied the concepts of decoupled complexity and distributed processing to allow for module independence.

Data Models
Human anatomic structures and physiologic models were approached as a multiscale modeling problem, leaving the door open to consider ever smaller compartments and increasing accuracy. [20][21][22][23][24] To ensure completeness and consistency we engaged two University of Washington teams that have worked with the NIH in establishing standards from Biomedical & Health Informatics. The organization of AMM in general followed the way the human body is structured and how systems communicate with each other.
As stipulated in the solicitation, the body was broken down into six segments: head, torso, and four limbs, each with its own compute module on board and the ability to function as independent part-task trainers. For patient-state-related data, we defined data structures for disease states, injury mechanisms, physical findings and lab results based on discussions with clinicians from over 30 specialties.

Connector Design
Performance requirements for strength, durability, and usability for the connectors were established based on the average for military personnel in full gear. The dimensional envelope was determined based on the proposed locations between the six segments and considered both the male and female anatomy. Throughput requirements were based on review of various existing patient simulators and part task trainers.
Connector Technical Requirements: • Blood channel flow rate:

Central Operating Resources
The same requirements used for the connector design were also used to select battery, fluid, and air components. The team evaluated several open-source real-time communication protocols based on requirements for data throughput, data integrity and latency.

Bench Testing
As part of the overall development process, a bench testing protocol was established. Testing followed the basic design paradigm of the platform by assessing modularity, interoperability, and its ability to support distributed processing. Modularity addresses how segments align, communicate, connect, and disconnect. Interoperability verifies that AMMcompatible simulators developed by third parties can actually connect and work with the platform in a clinically and educationally meaningful way. Distributed processing refers to the ability of segments to function as standalone part task trainers. To that end, testing considered running major segments as standalone trainers.
As the development effort progressed, critical system components were submitted for durability and reliability testing at the University of Minnesota. Considering modularity and the impact of the Universal Segment Connector that was designed for both the simulation center environment, as well for use in an austere environment, the connectors were subjected to four different tests: Considering the stipulation of a distributed computing environment during the design and prototyping phase, we tested operation of the integrated system, using two modules developed specifically for this project, as well as third-party modules that were connected using the AMM data and communication standards. During development, testing consisted of modules successfully connecting to the core, registering their capabilities and data exchange needs. This was validated by studying the system log files and by running complete scenarios depending on those modules successfully.

Usability Study
A pilot study, field testing of the platform's capabilities, usability, and functionality, was led by the American College of Surgeons Division Education at WWAMI Institute for Simulation in Healthcare in Seattle, WA. Four teams, consisting of first responders, anesthesiologists, and surgeons, paired with a confederate "nurse" and ran through a multirole trauma scenario whereby a single patient running on the AMM platform with the BioGears physiology engine, suffered blunt abdominal trauma and was treated in the field, triaged at a FOB and finally in an operating room with exchangeable modules and continuous physiology. Several interventions were performed across three "scenes" including but not limited to intravenous placement, field endotracheal intubation, fluid resuscitation, a dynamic physical abdominal exam, an abdominal ultrasound Focused Assessment with Sonography in Trauma (FAST) exam, rapid induction endotracheal intubation and trauma laparotomy with a splenectomy, cystography, and common iliac vein repair. Talk-aloud debriefs and recording of platform communication errors/inconsistencies after each scenario as well as a review of the data logs were performed to provide the development team feedback for the last phase of development.

RESULTS
The stipulated deliverables for the AMM program were a system architecture, data models, a universal connector design, and a reference implementation to demonstrate the operation and usability of the platform and finally documentation to allow interested researchers and industry to develop AMM-compatible modules. All current design-and documentation-related information was published as open source at www.advancedmodularmanikin.com. 25 Results for each major deliverable is described below.

Capture and Verification of Requirements
Given the multiple modalities being developed and utilized for training and assessment, the framework was designed to accommodate physical, virtual, and hybrid simulation capabilities under a single operating environment. The program requirements and approach were verified by JPC-1 during the final demonstration of Phase I with the stipulation that AMM should support military, as well as civilian training needs.

System Architecture
Based on internal testing and the pilot study completed at UW, the system architecture demonstrated decoupled complexity principles, such that local computations and decisions that did not require a systemic response, were successfully handled locally, and did not transmit to the core compute module (CCM). This was verified by reviewing data flow and communication between segments as limited to the data models created. During integration testing, we demonstrated the ability to concurrently run the physical manikin and the virtual patient using the same patient instance. The communication between modules was demonstrated to be successfully handled through DDS (Data Distribution Service) as described under communication protocol (Fig. 1). Where interdependence was essential, the information was disseminated through the CCM via DDS at the appropriate, clinically relevant level.
During bench testing, we verified that by leveraging the abilities of the DDS open standard, multiple patients could be

Data Models
The data models make up the heart of the AMM platform and are a critical component to ensure extensibility and scalability. The models were broken into three groups: system operation-related data objects, patient-related data objects (https://bit.ly/2ZkQcZ4), and learner-specific data objects.
System-related data addressed software and hardware release information, maintenance, and support-related data, and module capability information for dynamic configuration. System-related data were implemented at a rudimentary level to ensure routine operation of the platform.
Patient-related data were centered around patient physiology, but also addressed patient conditions, lab results, imaging studies, definition of the patient's anatomy, as well as patient-care-related information. The inner structure and completeness of the patient data were verified by reviewing them with multiple civilian and military healthcare providers at all levels of care. The anatomic datasets have been published on the AMM web site in multiple formats.
Full-body magnetic resonance imaging (MRI), 3D optical scan, and life-cast models of a male (age 35, height: 175 cm, leg length: 70.5 cm, arm length: 55.5 cm, weight 185 lb, body mass index 27.3) and female (age 37, height 168 cm, arm length 55.5 cm, leg length 66 cm, weight 147 lb, body mass index 23.0) provided the anthropomorphic boundaries. MRI data were segmented to create 3D models in AUTODESK MAYA and converted into SolidWorks files to support the generation of computer-assisted design. Rapid prototyping 3D printing and casting/molding methods were used to evaluate alternative designs. Weight and space utilization considerations were driven by the reference male and female patients that were selected for the project.
Learner-specific data allowed the platform to collect learner specific performance data and provide it for storage via the Data Logger. During bench testing and the pilot, patient data included definitions for all the cues that were rendered by the platform to elicit diagnosis of the patient condition and treatment decisions.

Connector Design
The Universal Segment Connector was engineered to have a uniform way to connect the six segments on the physical instantiation of AMM: head, torso, two arms, and two legs in anatomic positions deliberately avoiding stress points like joints (Fig. 2). We were successful in creating a singular component that works for all of these connections, fit within both the female and male adult reference anatomy datasets and is genderless, i.e., the same part is used on both sides.
The connector successfully passed all of the testing protocols.

Three Point Bending Test:
Mechanical: The connector was able to withstand a bending moment of 100 ft lb without sustaining any mechanical failure or deformation Electrical: The electrical contacts inside the connector remain in contact under an applied moment of 100 ft lb.
Fluid: Fluid was run through the connector's fluid lines without leakage, whereas the connector sustains an applied moment of 100 ft lb.

Vibration Test:
Mechanical: The connector was able to experience vibrations of frequencies ranging from 10 Hz to 1.5 kHz without sustaining any mechanical failure or deformation Electrical: The electrical contacts inside the connector remained in contact and operational, whereas connectoris subjected to vibration with frequencies ranging from 10 Hz to 1.5 kHz Fluid: Fluid was run through the connector's fluid lines without leakage, whereas the connector is subjected to vibration with frequencies ranging from 10 Hz to 1.5 kHz

Communication Protocol
The requirements for data throughput, data integrity, and latency led us to select Data Distribution Service for Real-Time Systems (DDS), an open standard-based service as the open-source communication protocol for AMM. DDS is a middleware protocol and API standard for data-centric connectivity from the Object Management Group. 26 An average AMM patient generates approximately 50 kilobytes of data per second (operating at 50 frames per second). All required source-code and libraries were successfully published to the AMM GitHub instance. Overall, loss of data/communication identified during the pilot was attributed only to modules failing. Otherwise DDS functioned as required, managing quality of service for the backbone. 90 W Power over Ethernet (PoE +) was chosen as the preferred method, and we built a custom board to accommodate this emerging standard. This decision allowed both data and power to use the same connectors and cabling.

Reference Design
Based on the system architecture and the requirements for central resources, a reference system was built comprised of a full body manikin, central resources and all the necessary hardware and software components needed to operate the system.

Reference Compute Modules
The team created a Developers' Kit (AMMDK) (Fig. 3). Building an AMM module requires communicating with the rest of the system, and connecting to the hardware sensors and actuators that define a module's capabilities. The AMMDK was used successfully in several modules during the pilot study. Unique to our hierarchical design, the same compute module was demonstrated running both as the CCM, as well as within some of the individual plug-in modules with an add-on board.

Module Manager
During both the bench testing and the pilot study, the module manager dynamically and successfully connected and disconnected modules that were brought into the system including the BioGears physiology engine. While connecting, it registered the identification and version number of the module with a scenario run, captured the set of capabilities a module provides, and documented what data a module requested to "subscribe to" and/or "publish back to" the system. When disconnecting, it made sure that any data required to properly document a simulation run was captured and archived by a Data Logger (described below).

Patient Manager
During the pilot, the patient manager successfully processed the complex patient scenario. This included the initial patient state at the beginning of the scenario, as well as conditional and nonconditional events that were triggered during the scenario.

Intermodule Communication Protocol
Leveraging the abilities of the DDS open standard, we were able to run two AMM patients on a single network in the labeach patient contained within a separate DDS domain, maxing out at 107 kbps between the two.

Data Logger
The Data Logger was currently implemented, captured all relevant data generated by the platform including connected modules during the pilot simulation run, and archived it into a relational database to support debugging and scenario testing.

Third-Party Integration
To date, several academic, government funded and industry developed modules went through systems integration and natively connected to the platform. So far none of the integration efforts have proven to be too onerous. The AMMDK helped our three external vendor pilot module developers connect to hardware peripherals by providing integrated microcontroller units capable of connecting to almost any peripheral sensor or actuator as well as the software tools to program and debug microcontroller unit code. The amount of labor to make an existing module AMM-compatible and integrate it with other modules varies with module complexity and the software architecture. It can be as little as 40 h, as was our experience integrating the University of Florida's Central Venous Catheter trainer that was developed following modern design principles. The applications that were integrated included physical systems with sensors, virtual patients, and real-time interactive graphic simulations. The System of Systems approach protected the IP of the individual developers as the inner workings of their modules were not exposed to other vendor modules.
During the pilot, we successfully connected third-party modules into our prototype system. All modules published physiologic parameters and conditions occurring within their simulations and had relevance to the system and subscribed to physiologic parameters and conditions that might affect their simulations. The core successfully served as a conduit for connecting modules across the system with common physiology and the overall "state" of the patient.

Usability Study
A study, to evaluate the platform's capabilities, usability, and functionality was led by the American College of Surgeons, Division of Education. The study used the reference design and was performed at the San Diego Naval Hospital, with the participation of 17 teams, same as described under Methods. The AMM platform was well received. The findings from that distinct study are being submitted by the American College of Surgeons.

DISCUSSION
The Healthcare simulation industry has delivered on some training needs; balancing the perceived market potential with their legacy product lines, manufacturing pipelines, and technological capabilities. Healthcare educators, on the other hand, have a need that is much broader that includes both common and rare diseases, conditions, and injuries. [27][28][29] The open-source AMM platform demonstrated the capability of accommodating interoperability, modularity, and distributed processing in an efficient and robust manner. It was easily adoptable and scalable as evident by the feasibility of thirdparty integration. It also allowed for complex scenarios across Roles and learner groups, providing interprofessional training opportunities and provided an important link with physiology. Multiple patient instances can be run on the same network, allowing for multicasualty scenarios, the data models can be expanded to address patient transfers by adding required resources. Given a gigabit network, the theoretical limit of patients on a single network is 18,000, and current hardware would limit us to several dozen patients. Overall, it offers an attractive solution to meeting the broad needs of the military healthcare community and its civilian counterparts.
As industries mature, open-source standards have been introduced to provide interoperability and accelerate the number of applications and capabilities. The success story of open-source programs such as Google Chrome, RedHat, and Mozilla Firefox are well documented. 30 In 2015, over 78% of companies were using open-source platforms. The call for an open-source/open standards platform for patient simulation has been in discussion for many years. The drivers have been 2-fold: First, the need to create comprehensive simulations for patient management that challenge interdisciplinary teams by using multiple simulators together to target decision-making, technical-skills, and team-based performance and second, to enable developers to rapidly create simulators at a lower cost point to address uncommon interventions. Until the DoD moved to fund such an effort, it had been resisted by industry as not being in their best interest. However, if we look at the success stories of Open-source projects, we see that they drive down development costs for many new products and applications, create a developer community that future proofs the platform, and grow the customer base.
It was a requirement that AMM be scalable to the needs of all healthcare providers, from first responders to sub-specialty providers. With the sizable investment made by the DoD and the open-source/no royalties stipulation, the R&D investment required for higher capabilities has already been made. Educators can now consider the use of a common platform that will allow higher level skills to be trained by any level trainee and allow them to make better decisions based on desired Learning Objectives. Figure 4 illustrates the current implementation and how it connects to the reference patient datasets.
The pilot successfully demonstrated the functionality of the system and helped to solidify details for a larger usability study conducted by the ACS (American College of Surgeons) Division of Education.

Future Development
As the first stable release has been published for review and comments, the team is looking ahead to expanded use-cases. At an administrative level, it will need to be determined how the open standards will be maintained and updated, and by whom. A process for determining "AMM compatibility" needs to be established. AMM development courses, kits, and documentation to support module development are being planned as CREST and other groups are developing AMM-compatible modules that are funded under separate mechanisms.

Limitations
Although feasibility and usability are described with this article, we did not specifically address educational value. The next step will be for the simulation community to build AMM-compatible modules to support military medicine applications and their civilian counterparts and to perform verification and validation studies on the specific training applications.

CONCLUSION
The AMM software platform and anatomic, hardware, and software standards are functional and demonstrate usability for supporting interoperability, interchangeability, and modularity to support healthcare simulation. All the work completed under this contract is being published under Creative Commons Attribution 4.0 International (https:// creativecommons.org/licenses/by/4.0/) with no royalties.

ACKNOWLEDGMENTS
We thank Maria Terry, MD, Marko Hananel, Esq., and Kristina Cizas for their critical review of the manuscript. We would also like to thank all team members, too numerous to list here: Over 40 of them over the last 5 years, for their tireless efforts and important contributions to this program. Finally, our thanks to the administrators at our two home institutions that supported this program while we moved our research team from the University of Minnesota to the University of Washington and had to work out the details and enable a smooth transition.

FUNDING
This work was funded by Department of Defense (Award# W81XWH-14-C-0101).