ammcrest_icon.jpg

Advanced Modular Manikin™ Phase 2 Standards

A Common Platform Towards a New Paradigm in Health Care Simulation

Open Standards    -    Distributed, Modular, Interoperable
Development Platform    -    Reference Patient & Reference System

 Principal Investigator: Dr. Robert Sweet    -    Principal Investigator, UW: David Hananel

Award #: W81XWH-14-C-0101




Licensing

by [Converted].png

The links below explain the platform's licensing agreement:

https://creativecommons.org/licenses/by/4.0/   

https://creativecommons.org/licenses/by/4.0/legalcode  


Purpose of this Web Site

This web site provides an introduction to AMM™, and serves as the primary entry point to information the team will be sharing with our community. In the next few months, as we ready drafts of the standards documents, we will create a link from this page to a document repository with tools for comments and feedback to commence a dialog leading up to the initial release of a comprehensive set of standards document that would allow any interested party to create a plug and play module that would use all resources provided by the development platform.

The terms: Advanced Modular Manikin; AMM; and AMM-Compatible will be Copyrighted and belong to the AMM project and platform. As part of the open-standards and open-source nature of the project, they are not intended to be used as a product name, but can be used by products that comply with the standards once published.


A Development Platform

The University of Minnesota and the Center for Research in Education and Simulation Technologies(CREST) are the recipients of DOD Award # W81XWH-14-C-0101.

The deliverables consist of a modular, distributed, interoperable architecture patient simulation with open standards for all the relevant data models, communication protocols, physical connectors, a reference patient and reference hardware for core resources that will be published in draft form for comments, then finalized and published. The software that is part of the core system will be made available under an open source license.


What AMM is not

A Manikin

Although the name implies a manikin, it is much broader. It is a platform that brings together many modalities (Physical, VR, AR) with a common objective:

Ability to render the state of the patient so it can provide cues required by providers to make decisions.

Ability to sense actions taken by providers such that it can influence the state of the patient as required.

Ability to capture decisions and actions such that they can be used for performance evaluation.

 

A Commercial Product

The result of the AMM Phase II project is not a ready to ship commercial product or a package of information from which one can build a commercial product.

Rather, it is a set of standards and reference designs upon which any interested part can design and commercialize a product.

The AMM team is putting together a prototype system to demonstrate the functionality of the standards and reference designs based on work being done under other projects and some industry players.

 

A Complete Design That Can Be Sourced

The final deliverables of the AMM project is not a complete set of designs and specifications from which one could manufacture a complete system.

Rather, it is standards and reference designs that represent the core building blocks upon which others can create compatible segments and modules.

 

A Final Set of Standards

The standards that are being published, although necessary and sufficient considerations, by design are intended to be extensible by following a set of guidelines to allow for future developments.

 

A One Company Solution

Although a company can choose to build a complete system, the standard interfaces that have to be used to be deemed AMM compatible ensures that at the segment level, product offerings remain interoperable.

Within segments, companies may choose to be proprietary.

 

A Research Project

Although the Platform can be used to support Research Projects, the deliverables from the AMM project will be ready to be implemented into commercial solutions, with some core components set for low volume production based on demand.


Background

As stated in the announcement for the Advanced Modular Manikin ™ (AMM™) and detailed in the solicitation W81XWH-13-R-0032 from JPC-1, the program seeks to:

 “Advance the state of the art in medical simulation based training. It is anticipated that the core AMM system will 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.

The intent is that the AMM be a platform upon which future technologies can reside through development of advanced peripherals through other efforts. It is envisioned that the advanced modular manikin be compatible with a wide array of peripherals and/or extensions leveraged with open-source / open-standard physical attachments, supply (electrical/fluid) connections and communications links. This broad AMM platform to be developed should have the ability to host capabilities that do not yet exist but that are anticipated to be developed within the next five to ten years. Creation of the AMM platform will allow for a usable manikin system that can incorporate future advances, from a variety of sources, easily into military medical training.”

The creation of the open-source platform and the establishment of the open-standards resides with the Center for Research in Education and Simulation Technologies (CREST), at UMN and UW.


Components of the Platform

    

Hardware

  • Development kits for compute modules and real-time boards

The CREST team is developing a set of reference designs for the real-time compute modules and the analog boards that connect to any needed sensors and actuators within the plug in educational modules, such as an IV Arm or Intubation Head.  We are developing these to demonstrate the functionality of the AMM Platform. The designs will be documented and published as part of the deliverables for this project.  CREST will attempt to secure a source that can deliver the reference hardware kit at a reasonable cost for development teams to facilitate their design process.

The expectation is that as modules are readied for commercialization, the industry participants would use the reference design as an example but would develop their own hardware based on the published Open Standards.

  • Relevant architecture documents and design guides

The CREST team will publish a complete set of documentation for the AMM Architecture, including the design guidelines, sample documentation package for the module design process.

  • Standard connector designs for head, arms and legs

The CREST team is developing the standard connectors for head, upper and lower extremities to connect to the torso, providing the physical connection as well as power, data, fluid and air supplies as part of the core supplies to the manikin. CREST will deliver a complete set of engineering drawings, material selection Bill of Materials for commercial components that are used and a guide to incorporate these connectors into plug-in module designs.

CREST will attempt to secure a source that can deliver the reference connectors at a reasonable cost for development teams to facilitate their design process.

The expectation is that as modules are readied for commercialization, the industry participants would use the reference design as an example but could develop their own hardware based on the published Open Standards with their own supplier network.

  • Reference design documentation for power, fluid and air supply for development platform

The CREST team is developing a design for central operating resources for the AMM platform to include power and power management, fluid and pressurized air and their management across all plug-in modules.  The control hardware will be identical to the one used for the plug-in modules, and the required software will be available as part of the open standards package.  The performance specifications will also be published as part of the final design package.  This capability can be external or internal to the manikin, and if internal can be located in any part of the manikin as required by the training needs and space/weight trade-offs.

  Low-definition CAD anatomy assembly

Low-definition CAD anatomy assembly

 

Software

  • Simulation state engine

The state engine that allows the desired training scenario to advance and unfold.  It is being developed as a plug-in module itself and is part of the open-standards, open-source package.

  • Simulator state engine

The state engine that allows for the dynamic configuration of the manikin platform based on modules that are plugged in and supervises the state of the hardware platform. It is being developed as a plug-in module itself and is part of the open-standards, open-source package.

  • Connection to physiology engine

There currently are multiple physiology engines in existence.  BioGears has been funded by the same agency as the AMM platform.  It will serve as the reference standard.  Physiology data is the most important data set that is used by the AMM platform to connect all modules and make them behave as a complete patient.  As such, it is important to allow users to decide which physiology engine best supports their training needs. The CREST team is working on having a physiology engine agnostic standard interface available, so that plug-in training module developers do not have to adjust to each of the available physiology engines.

  • Communication protocol and necessary plug-ins

For the data communication aspects between all modules, the AMM platform is using the Data Distribution System (DDS) standard that was developed as a Real-time Publish-Subscribe Wire Protocol.

http://portals.omg.org/dds/what-is-dds-3/

  • Framework for real time compute modules and communication schemas to sensors and actuators

The following graphic illustrates the basic building blocks for AMM, the dark blue blocks are part of the AMM program, the physiology engine is a required component and is not funded by the AMM project.  The Auxiliary Processes are a link to future enhancements but the data set definitions will have to be shared. These are programs such as learning management systems, debrief facilitators, scenario creation tools etc.

Modules can be either plug in technical skills trainers as part of the anatomic structures, or they can also be items like monitors, devices, VR trainers, display systems. They all communicate via the DDS facility and are treated the same way by the state engines.

processes.png
  • Data Objects

We are defining four data objects for the AMM platform. They will draw upon multiple data sets to populate along with time.

  • Synthetic Patient
  • Learner
  • Scenario
  • System    

 

  • Reference Data Sets

  • Physical Findings - All cues that are recognized by providers to diagnose patient and need to be rendered by the system
  • Physiologic Variables (OPB)
  • Diseases
  • Procedures
  • Systemic Responses
  • Segments – Defined as the torso, upper and lower extremities
  • Sub-segments – Hierarchically the next level down in plug in modules based on training needs
  • Emotional response – Initially set as Anger, Disgust, Fear, Joy, Sadness and Surprise
  • Clinical, patient data - What, where, when, as would be included in the EMR
  • Environmental data - Ambient temperature, light, humidity, oxygen concentration, etc.
  • Student performance data – Performance data as defined by Educational Requirements and program of instruction, formatted per AMM standards
  • Module technical data - ID of module, version number, diagnostic information, performance information
  • Drug data - What, where, when, how

Our Community

The IP directly resulting from this contract will be made available to the health care simulation community with no royalties.

Our community includes academic institutions, professional societies, industry participants and all other entities that would like to develop new training modules, performance assessment and management tools, scenario creation tools, as well as analytic tools.


Dictionary

     System Components

  • CORE – (Central Operating REsources ) the basic software/hardware platform that manages all aspects of the modular manikin and via standard interfaces allows all interested parties to create add-on futures to the system
  • Segments – Sections of the human body that have been defined by considering reliability, standard connection points and conflict with interventions
  • Physical Patient Modules – Individual training units that can be configured, from part task trainers to body segments, to multiple segments based on the training requirements of medical interventions or program of instruction (POI) they communicate with the core via the Data Bus
  • Peripheral Modules – Software and/or hardware modules that complement the Physical Patient based on training needs, such as Patient monitor, Ventilator, Surgical Devices, Surgical VR Simulators,  IV Drip, etc
  • Plug-ins – Peripheral software modules that connect directly to the core via a published SDK, like the Physiology Engine, LMS, etc
  • Data Bus – The sole real time data exchange mechanism between all modules in the system and the CORE

 

     Data Domain

  • Clinical, patient data - What, where, when
  • Physical Findings - All cues that are recognized by providers to diagnose patient and need to be rendered by the system
  • Environmental data - Ambient temperature, light, humidity, oxygen concentration
  • Student performance data - Metrics as defined by Educational Requirements and program of instruction
  • Content data - TLO, task, condition & standards
  • Module technical data - ID of module, version number, diagnostic information
  • Drug data - What, where, when, how

Documentation Tree