SN Comprehensive Clinical Medicine

, Volume 1, Issue 5, pp 362–377 | Cite as

Pulse Physiology Engine: an Open-Source Software Platform for Computational Modeling of Human Medical Simulation

  • Aaron Bray
  • Jeffrey B. Webb
  • Andinet Enquobahrie
  • Jared Vicory
  • Jerry Heneghan
  • Robert Hubal
  • Stephanie TerMaath
  • Philip Asare
  • Rachel B. ClippEmail author
Part of the following topical collections:
  1. Topical Collection on Medicine


The Pulse Physiology Platform is an open-source software application designed to enable accurate and consistent, real-time physiologic simulations for improved medical training and clinical decision-making tools. The platform includes a physiology engine comprised of well-validated lumped-parameter models, differential equations representing feedback mechanisms, and a pharmacokinetic/pharmacodynamic model. The platform also includes a common data model for standard model and data definitions and a common software interface for engine control and robust physics-based circuit and transport solvers. The Pulse Platform has been incorporated into a number of commercial, research, and academic tools for medical simulation. Significance: The Pulse Platform is an innovative, well-validated, open-source tool for medical modeling and simulation in the training and clinical decision-making field.

Graphical Abstract

The Pulse Physiology Platform includes a common software interface, a common data model, and the Pulse Physiology Engine. This platform supports a modular, extensible architecture for real-time simulations of the human physiology with validated physics-based computational physiology models.


Lumped-parameter Medical modeling and simulation Open-source software Patient-specific modeling Whole-body physiology 


Many areas of medicine have shown that clinicians lack the skills and confidence necessary to quickly and efficiently treat patients [1, 2]. This is particularly true for emergency, military trauma, and critical care medicine. Simulation has been widely adapted in many areas of medicine, including anesthesia and trauma care and been shown to be highly effective in improving clinical confidence and skills [2, 3, 4, 5, 6, 7, 8, 9, 10, 11]. Current training techniques include traditional didactic materials, virtual training scenarios, manikin simulations with and without physiology, and live patient simulations.

However, current training methodologies have significant limitations. Expert feedback is required before, during, and after the scenario to ensure accurate physiologic responses are supplied to the trainee. This style of instructor-driven scenarios significantly limits the number of trainees with access to high-quality training. Virtual physiology engines, both open-source [12, 13] and proprietary [14, 15, 16], provide a powerful alternative. Virtual physiology engines have been paired with manikin simulations and virtual training scenarios to create a more realistic training scenario that can react in real-time to a trainees’ actions without pre-scripting [17, 18, 19, 20].

High-fidelity models, such as Lattice–Boltzmann, finite element, and computational fluid dynamic models, exist and are a key to improving diagnostics and predictive medicine. Some of these tools, such as SimVascular [21] and OpenSim [22], are available as open-source toolkits. However, the computational requirements for these high-fidelity approaches do not lend themselves to the real-time whole-body physiologic responses required to power training simulations. Best fit, empirical models, and state-based systems are used for many simulation scenarios. These options are based on data collected for specific scenarios and rely on the user selecting treatment and trauma from a limited set of options. They do not provide a robust, well-validated modeling approach that can be used for a variety of physiologic conditions. Lumped-parameter or zero-dimensional modeling is based on physics principles that link the body’s physiology responses to electrical analogues [23, 24, 25, 26, 27, 28]. These relationships provide physics-based models that can be validated and modified to cover a wide variety of conditions, while still providing computational efficiency. A few existing physiology engines use this methodology, including HumMod [29, 30], BioGears [31, 32], and the Pulse Physiology Engine. However, only BioGears and Pulse are open-source.

Open-source development has several major advantages that have been previously published [33]. Some of these benefits include:
  1. 1.

    Encourage collaboration between academic, clinical, commercial, and government intuitions through a common software platform and fostering a sense of community.

  2. 2.

    Save costs and resources by reusing and repurposing software solutions and investing in new research methods and custom commercial applications.

  3. 3.

    Validation and verification algorithms and data are often included to provide a benchmark and ensure robust and validated software.

  4. 4.

    Permissive licenses allow for users to use technology without restrictions.


BioGears is a Department of Defense program with the goal of lowering the barrier to entry for medical training and simulation content developers by supplying an open-source physiology engine that produces reliable, accurate, and validated physiologic responses to major physiologic conditions with military relevance. BioGears has some significant limitations, such as a licensing issue that may limit the commercial use rights of third party applications, a lack of an active public repository, and a lack of community contribution. The Pulse Physiology Engine is a fork of BioGears. It was created by the original developers of BioGears to address these concerns and continue to develop physiologic models with relevance to both the military and civilian communities. Pulse addresses the licensing issues of BioGears and has a permissible Apache 2.0 license. Pulse is also accessible via a public repository that has a number of users and outside contributors to foster a true open-source community. The Pulse Physiology Platform has also been integrated into a number of research, clinical, and commercial applications, as further discussed in the “Case Studies—Community Adoption” section of the paper.


The Pulse platform supports the design, development, and use of physiologic modeling for building medical training content. The architecture was specifically designed to reduce model development time and increase the usability of the engine in simulations by creating a modular, extensible definition for human physiology. To accomplish these goals, the Pulse platform includes the Pulse Physiology Engine, a common data model (CDM), and a Software Framework, as shown in Fig. 1. Both the CDM and framework were designed to support computational physiology models in general by providing a standardized data interchange between physiology models and users. The Pulse Physiology Engine is one example of these computational physiology models.
Fig. 1

The Pulse Platform includes a common software interface, a common data model, and the Pulse Physiology Engine. This platform supports a modular, extensible architecture for real-time simulations of the human physiology

Pulse Physiology Engine

The Pulse Physiology Engine is comprised of numerical models that represent the different systems of the body, the feedback mechanisms and interactions between the systems, pharmacokinetics/pharmacodynamics, and medical equipment. These numerical models are designed, implemented, and validated to provide consistent and accurate physiologic output/feedback across a wide-range of medical training applications. The differential equations contained in each system are calculated through transient analysis with a shared time step. The numerical models currently execute with a time step of 20 ms to ensure all physiology features of interest are captured, while maintaining real-time execution for the simulation.

Lumped-Parameter Models

The major systems are modeled using lumped-parameter models, which are circuit analogs to represent the dynamic behavior of the physiologic systems. The circuit analogs use resistors to represent the resistance to flow through blood vessels, airways, and equipment and capacitors to represent the ability of those same components to dilate and constrict. The numerical evaluation of these circuit results in pressure, flow, and volume predictions for specific organs/regions of interest of the body. While lumped-parameter models have been commonly used to model different physiologic functions and behavior [23, 24, 25, 26, 27, 28, 34], it is rare for them to be linked to create a whole-body physiology model. This novel implementation uses the flexibility of these models to create varying fidelities across different systems to model not only the physiologic function on individual system, but the ability of those systems to interact with each other (Fig. 2). For example, the cardiovascular system models the vasculature of the specific organs in the body, while the respiratory system models the different components of the lung airways. These two systems then interact across the pulmonary capillary–alveoli barrier to allow for gas transfer. This extension incorporates partial pressure diffusion between a liquid (blood) and a gas (air) by leveraging the multi-fidelity lumped-parameter model results for pressure and volume in the capillaries and airways. Medical equipment can also be incorporated by linking lumped-parameter models. The anesthesia machine model is linked to the respiratory system via the mouth and the mask/endotracheal tube to represent assisted breathing/intubation (Fig. 2).
Fig. 2

The Pulse Physiology Engine is comprised of lumped-parameter models, circuit analogs, that represent the systems of the body and medical equipment

The individual parameters of the lumped-parameter model can also be modified and scaled based on the modeling needs of a specific condition or disease. For example, in renal stenosis, the resistance associated with the renal artery is increased to represent the constriction of the stenosed blood vessel. The resulting renal pressure and flow are then affected by this change. This causes additional effects within the renal system, such as changes in glomerular filtration rate. Similarly, feedback mechanisms can affect individual parameters providing a means for incorporating drug effects and baroreceptor functionality into the whole-body physiology engine.

Feedback Mechanisms—Baroreceptors

A variety of feedback mechanisms are modeled and integrated with the lumped-parameter models, such as baroreceptors and chemoreceptors. These models calculate a response based on parameters from different physiologic systems, including the cardiovascular and respiratory systems, then apply the response back to the system.

The baroreceptor mechanism provides rapid negative feedback control of arterial pressure. A drop in arterial pressure is sensed by the baroreceptors and leads to an increase in heart rate, heart elastance, and vessel distensibility. These changes operate to maintain mean arterial pressure (MAP) at its healthy resting level. The Pulse model, adapted from Otteson, et al. [35], drives the mean arterial pressure towards the resting set-point by calculating the sympathetic (1) and parasympathetic (2) response.
$$ {\eta}_s\left({P}_a\right)={\left[1+{\left(\raisebox{1ex}{${P}_a$}\!\left/ \!\raisebox{-1ex}{${P}_{a,\mathrm{setpoint}}$}\right.\right)}^{\nu}\right]}^{-1} $$
$$ {\eta}_p\left({P}_a\right)={\left[1+{\left(\raisebox{1ex}{${P}_a$}\!\left/ \!\raisebox{-1ex}{${P}_{a,\mathrm{setpoint}}$}\right.\right)}^{-\nu}\right]}^{-1} $$
Where, ν is the response slope of the baroreceptors; Pa is the MAP, and Pa, setpoint is the MAP setpoint. These responses are then used to calculate the changes to the heart rate (3) and elastance (4) and systemic vascular resistance (5) and compliance (6).
$$ \frac{dHR}{dt}=-\frac{1}{\tau_{HR}}\left(- HR+{\alpha}_{HR}{\eta}_s\left({P}_a\right)+{\beta}_{HR}{\eta}_p\left({P}_a\right)+{\gamma}_{HR}\right) $$
$$ \frac{dE}{dt}=-\frac{1}{\tau_E}\left(-E+{\alpha}_E{\eta}_s\left({P}_a\right)+{\gamma}_{HR}\right) $$
$$ \frac{dR}{dt}=-\frac{1}{\tau_R}\left(-R+{\alpha}_R{\eta}_s\left({P}_a\right)+{\gamma}_R\right) $$
$$ \frac{dC}{dt}=-\frac{1}{\tau_C}\left(-C+{\alpha}_C{\eta}_s\left({P}_a\right)+{\gamma}_C\right) $$

Where, HR, E, R and C are the relative values of heart rate and elastance, and vascular resistance and compliance, respectively; τ represents the time constants for each value, and α, β, and γ are tuning variables used to achieve the pressure shifts required to accurately model the baroreceptors. More information on how the tuning parameters were set can be found in [36]. These time-dependent changes are then applied to the cardiovascular system by modifying the lumped-parameter components, including scaling the resistors associated with the arteries, the capacitor associated with the vena cava, and the rate and elastance of the heart driver.

Pharmacokinetic/Pharmacodynamic Models

Physiologically based pharmacokinetic (PBPK) modeling is a technique that mathematically models the distribution, uptake, metabolism, and clearance of a drug with consideration of the relevant physiological processes [37]. Pulse has both pharmacokinetic (PK) and pharmacodynamic (PD) models. The PK model matches the fidelity of the cardiovascular and respiratory systems because it is linked to the blood and air transport and tissue models. The PD model is currently a lower-fidelity model based on a direct relationship between the plasma concentration and maximum effect for a system level response, such as heart rate, respiration rate, and blood pressure.

A drug enters the body through either injection or inhalation and moves through the body using the substance transport methodology discussed in the “Common Software Framework” below and shown in Fig. 4. Drugs move from the bloodstream into the tissues using perfusion-limited diffusion. The physicochemical properties of the drug are used to calculate the partition coefficient, which describes the affinity for the particular drug to diffuse across the barrier between the cardiovascular and tissue spaces. The details of this calculation can be found in [38].

The diffusion of the drug is calculated using (7).
$$ \varDelta M={Q}_T\times {C}_V-\frac{Q_{\mathrm{T}}\ast {C}_T}{K_P} $$
Where, ΔM is the change in mass due to diffusion; QT is the blood flow to the organ; CV and CT are the concentration of the drug in the organ vasculature and tissue, respectively, and KP is the partition coefficient for each drug and organ. An example of this calculation for a very weak base, acid, or neutral drug is shown in (8), details of these calculations and the data used can be found in [37, 39, 40, 41, 42].
$$ {K}_P={f}_{EW}+\frac{X+{f}_{IW}}{Y}+\frac{P+{\mathrm{f}}_{INL}+\left(0.3\times P+0.7\right)\times {f}_{NP}}{Y}+\left[\left(\frac{1}{f_u}-1-\left(\frac{P\times {f}_{NL}\left(0.3\times P+0.7\right)\times {f}_{NP}}{Y}\right)\right)\frac{PR_T}{PR_B}\right] $$
Where, X and Y are different relationships based on the ionic state of the drug (acid, base, etc.); fIW and fEW are the fraction of intracellular and extracellular water, respectively; fNP and fNL are the fraction of neutral phospholipids and lipids in the tissue, respectively; P is the octanol:water partition coefficient for the drug; fu is the fraction of the drug unbound in plasma, and \( \frac{PR_T}{PR_B} \) is the tissue to plasma ratio of the binding protein.

The drug clearance is specified by the user in the drug properties with an intrinsic, renal, and systemic clearance. The total drug cleared from the body is a total of these three clearance types. After diffusion and clearance have been calculated, the plasma concentration is calculated.

With accurate plasma concentration, the effects of the drug on different system level parameters can be calculated. The relationship between the maximum expected effect of the drug and the plasma concentration is shown in (9). This does not account for activity outside of the expected drug behavior, such as overdose responses.
$$ \varDelta E={E}_b\ast \frac{E_m\ast {C}_P^{\eta }}{EC_{50}^{\eta }+{C}_P^{\eta }} $$
Where, ΔE is calculated effect; Eb is the current value for the effect (i.e., heart rate); Em is the expected (or maximum) effect; EC50 is the concentration associated with a 50% effect response; CP is the plasma concentration for the drug, and η is the slope factor of the response [43]. The effects are then applied in the individual systems. The EC50 value is calculated using (10).
$$ {EC}_{50}=\frac{C_{max}}{32} $$

Where, Cmax is the maximum concentration for a standard dose. These calculations are completed for each physiologic effect per drug. The effects are then applied in the individual systems, i.e., blood pressure changes are implemented by modifying the systemic vascular resistors in the cardiovascular system.

Common Data Model

The CDM is an implementation agnostic specification of the data and relationships associated with physiology simulation software. A conceptual model to define and scope all of the definitions and relationships needed to simulate physiology was created. Based on the conceptual model, a logical model comprised of data structures was implemented. After a comparison and review of multiple interface definition languages (IDL), Google Protocol Buffers (Protobufs) was chosen to implement the logical model. Protobufs provides a small, platform-neutral mechanism for efficient serialization of structured data and supports a wide range of languages, including C++, Java, Python, C#, and JSON. Multi-language communication is necessary for communicating data between applications that use different languages. This was deemed a critical requirement for encouraging wide user adoption. Protobufs also supports object-oriented design style concepts, such as encapsulation, nesting, and packages. Protobufs inherently provide a method to define lightweight data structures that are easily adapted to many common communication messaging protocols. This allows the CDM to easily be leveraged by a simulation in both a local and distributed data system (DDS) environment. The CDM also promotes modular and extensible designs by providing a means of data interchange between models within a physiology engine and between any application and a physiology engine.

The CDM defines the scope and data required for physiologic simulation with the following concepts: patient, conditions, actions, substances, systems, and compartments.


The patient data object contains the parameters used to define a patient, including age, sex, weight, height, and baseline heart rate and blood pressure. The majority of these parameters can be user-defined to provide patient variability across medical simulations. The patent data is then accessed by the physiologic models to accurately represent a specific patient.


Patient conditions are persistent or recurring chronic conditions. They cause the body to enter an altered stabilized state, a level of homeostasis, that will alter the continual feedback mechanisms that take place in a healthy body. These condition types are typically defined by a severity scale in the CDM and physiologic systems alter their models accordingly. A few examples of chronic conditions are anemia, chronic obstructive pulmonary disease, and renal stenosis.


Actions are the only means to introduce input into an initialized engine. Actions generally apply an acute traumatic event (e.g., hemorrhage or pneumothorax) or a treatment step (e.g., intravenous fluid and/or drug administration or needle decompression.) Each action is defined as a Protobuf message in the CDM. On introduction of an Action, a physiology engine can dynamically apply any changes to its models during its execution for real-time, dynamic physiologic responses.


A substance object is defined by a number of chemical and physical properties, including molar mass, density, and relative diffusion coefficient. Substances circulating in the system can include basic gases, such as oxygen, defined by a minimum number of parameters, and complex drug substances, such as succinylcholine that are defined with PK/PD properties. A list of active substances is maintained, and the calculated substance parameters, such as plasma and tissue concentrations, are stored on the substance object.


A system encapsulates the data needed to describe a specific physiology system, piece of medical equipment, or external environmental condition. System data is also the calculated output of a physiology engine. It is not required that all system properties be calculated by an engine. They are also intended to be used as a means of data interchange between models within a physiology engine. An example of some systems and their properties are listed in Table 1.
Table 1

System data structure definition

System object

Data example


Altitude, air temperature, humidity


Heart rate, mean, arterial, diastolic, and systolic blood pressure


Glomerular filtration rate, osmotic pressure


Respiration rate, tidal, and lung volume


A compartment is another way to get output from a physiology engine. They represent the physics-based dynamics of an anatomical organ or region of interest (e.g., kidney, skin, or aorta), the environment, or an equipment component (e.g., anesthesia machine ventilator or inhaler chamber). Every physiology engine can define and discretize their own unique set of compartments to represent their models. The compartment types and physics-based properties are shown in Table 2. Compartments can be combined to create parent/child relationships, as shown in Fig. 3. Parent compartments aggregate data from their children, such as the parent compartment volume is simply the sum of each of its children’s volume.
Table 2

Compartment types and properties




Volume, pressure, flow, substance, mass/concentration, volume/volume fraction


Heat, temperature, transfer


Tissue to plasma ratio

Fig. 3

Compartments have parent child relationships. An example of this structure is shown for the heart and its child compartments, including the right and left hearts, the myocardium, and the pericardium

Common Software Framework

The common framework library was designed to reduce development time by providing a place to implement common reusable algorithms to ensure consistent fundamental functionality between programs. Implementation of these common algorithms provides reusable, validated, and supported algorithms that reduce model development time and provide consistent results.

These algorithms include the physics-based solvers and various data manipulation routines. The framework also includes a control interface, which standardizes simulation inputs, outputs, and execution of the physiology engine. As the Pulse Physiology engine is implemented in C++, the foundation library is also implemented in C++. Secondary frameworks are implemented in both Java and C# to provide limited data access and control of the physiology engine.

Physics-Based Circuit Solver

A generic circuit solver was implemented to centralize and solve the lumped-parameter circuit math. This generalized calculation ensures an accurate and consistent solution that can be reused for any models using circuit analogues. Because Pulse calculates the state of the patient at each time step, the circuit solver must function with dynamic circuits. This dynamic implementation of the circuit solver provides additional modeling flexibility by allowing the addition, removal, and/or modification circuit elements during simulations.

The requirements for solving the lumped-parameter models include adherence to an Apache 2.0 license, C++ compatibility, and the dynamic implementation of circuits. Prior to implementation, variations of the SPICE general purpose circuit simulation program [44, 45] were evaluated. However, these solutions had significant drawbacks, including slow execution time and memory leaks that led to issues as simulation length increased. Due to these limitations and the licensing requirements, an open-source, robust, validated, and closed loop general circuit solver was developed and implemented. The circuit solver is designed to allow for extraction out of the Pulse architecture for use as a standalone application. The circuit definitions and solver methodology allow for unlimited scaling.

Circuits are defined in the CDM through paths connected by source and target nodes. C++ templates were leveraged to allow the circuit solver to operate with generic variable and element types using native electrical, fluid, and thermal units, as shown in Table 3 [46]. The circuit solver uses modified nodal analysis to determine all circuit values each time step. This technique leverages branch constitutive equations (i.e., voltage-current characteristics) and Kirkoff’s Laws [47]. The key feature of modified nodal analysis is assuming the sum of all path fluxes connected to each node is zero—inflows equal outflows. To achieve this balance, the solver iterates over all nodes contained in the circuit to generate a set of linear equations in the matrix form Ax = b. The flux equations are shown in Table 4. Switches, valves, and polarized elements have states with required behavior criteria, as shown in Table 4. These element states cannot be directly determined, but must be assumed and iteratively solved until a valid combination that meets all criteria is found. The matrix form of the solution can be further defined by (11).
$$ \left[\begin{array}{cc}G& B\\ {}C& D\end{array}\right]\left[\begin{array}{c}v\\ {}j\end{array}\right]=\left[\begin{array}{c}i\\ {}e\end{array}\right] $$
Table 3

Circuit types and elements




Potential, flux, quantity


Voltage, current, charge


Pressure, flow, volume


Temperature, heat flux, heat

Table 4

Element types and flux equations


Flux equation (F)


Solve directly


\( F=\frac{P_S-{P}_T}{R} \)


\( F=C\frac{P_S-{P}_T}{dt} \)


\( F=\frac{P_S-{P}_T}{L} dt+{F}_0 \)

Potential source

Solve directly

Flux source

F given


State: open criteria: user defined F = 0

State: closed criteria: user defined solve directly

Valve (i.e., diode)

State: open criteria F ≥ 0 F = 0

State: closed criteria PS − PT < 0 solve directly

Polarized element

State: open criteria F ≥ 0 F = ∞

State: closed criteria PS − PT < 0 element equation

Where, G is the interconnection between passive elements; B and C are the connections between potential sources; D is zero because only independent sources are considered; v and j are the potentials and fluxes, respectively; i is the sum of fluxes through passive elements, and e is the independent potential sources.

The Eigen template library for linear algebra was used to solve the matrix equation. A number of algorithms within Eigen were tested for efficient and accurate matrix calculations. The SparseLU factorization for general matrices was found to be the most efficient; however, the Pulse Circuit Solar is designed to shift to the slower, but more robust FullPivLU linear solver when the SparseLU factorization fails to ensure accurate results. The quantities associated with paths with capacitance are incremented using (12).
$$ Q={Q}_0+ Fdt $$
Where, Q is the flow; Q0 is the flow at the previous time step; F is the flux, and dt is the time step.

Physics-Based Transporter

Contained within the fluids (i.e., blood, air, and urine) of the human body are substances that must move throughout a circuit. The requirements for the transporter were computationally efficient, dynamic, robust, generic, and extensible. The transporter must also conserve mass in all forms with an indefinite number of upstream and downstream bifurcations, and be able to handle potentially large flows with significantly more volume moved each time step than instantaneously exists in a given compartment. As this was unavailable for integration, the design and implementation of a generic substance transport methodology that could be applied across multiple systems were needed.

Unlike the Pulse Circuit methodology, the Pulse Transporter methodology is implemented on a compartment basis rather than the circuit basis. Compartments as defined in the CDM are linked via a flow and volume component. These links form a complete description of the identified region known as a graph. An example of a graph portion is shown in Fig. 3.

The transporter is implemented generically for both liquid and gas systems using the same high-level definitions for substance properties: the extensive property, which is proportional to the amount of material in the system (i.e., mass and volume) and the intensive property, which is not dependent on the system size or the amount of material in the system (i.e., concentration and volume fraction) [48]. The transporter assumes that fluid movement (i.e., convection) has already taken place. To calculate the resulting compartment substance values each time step, the transporter iterates over all compartments present in the given graph and completes a mass balance (13).
$$ \varDelta m=\sum {m}_{in}-\sum {m}_{out} $$
Where, m is the mass on the current compartment and min and mout are determined from the graph links to adjoining compartments. This mass balance can be further defined as (14).
$$ E= IV-\sum {I}_S{Q}_It+\sum I{Q}_O dt $$
Where, E is the extensive property (mass, substance volume); I is the intensive property (concentration, volume fraction); S denotes the source compartment; QI is the inlet flow; QO is the outlet flow, and dt is the time step. By combining this equation for all compartments in a graph, the linear equations can then be written in the matrix form Ax = b to solve for the intensive properties. Where, A is the matrix of constants; x is the vector of all intensive properties, and b is the vector of known previous time-step extensive properties. Each row represents the final mass balance equation for each compartment in the graph. As with the Pulse Circuit Solver, the Eigen template library was used to determine the solution. The same technique leveraging the Eigen template library described in the circuit solver section is used to determine a solution. The result is the entire advective transport by bulk flow for the graph.

General Data Manipulation and Support

Every CDM object has a matching implementation in the framework. These objects provide access to the CDM data and the supporting functionality, as outlined in Table 5.
Table 5

Common software framework functionality




Each object can serialize their associated Protobuf object.

Unit conversion

All scalar data is defined by a double and a unit and is capable of converting any value to any unit of the scalar quantity (i.e., volume, mass).


Objects can return the associated scalar data based on a given string containing the CDM property name (i.e., “HeartRate,” “RespirationRate”) allowing applications the ability to dynamically access CDM Data.


Objects are able to validate their contents to ensure realistic values (i.e., limits and bounds such as fraction groups summing to one).


Executes the engine for a specified time and checks that specified data (such as heart rate, tidal volume) stay stable within a specified percent for a specified amount of time. When the engine has reached this convergence point, it is considered to be stable.

Common Physiology Interface

A single interface defines all methods for inputs, outputs, and physiology engine controls. Various utility methods are supplied to query timing of the engine, such as the simulation time step of the engine and the current simulation time. Methods are specified to initialize an engine with either a patient and conditions or with a previously serialized state of an engine instance. After this initialization, the interface can accept input from the user. Input is provided by either advancing time or by providing action message. The physiology engine dynamically calculates all of its models per time step; therefore, time must be explicitly advanced. At the end of each simulated time step, the engine populates the data in various CDM systems and compartments, which is then available for user access. The interface also provides methods to save its state, or load a new state after advancing time. This state is physiology engine specific, because an engine may contain more data than is defined in the common data. Because the CDM is populated after each time step, processing of actions and data retrieval should not be requested during engine execution. Multi-threaded systems must be aware of this limitation to prevent an engine failure due to both advancing time and requesting input/output data, simultaneously.

Software Process

Our software process focuses on creating interfaces and models that provide end users with easy access to an accurate, validated physiology engine. By providing a common software framework, the focus is on developing consistent models that can easily be understood and trusted by medical experts. Pulse also supports a simple and intuitive interface for software developers with little medical knowledge that will allow them to easily integrate Pulse into a wide variety of medical simulation applications. We follow a software process that ensures production quality software.

Version Control System

Pulse uses the public Git repository, GitLab. Git is a version control repository for managing the complete history of a code base. GitLab is a cloud-based server where multiple parties can share a Git repository. Having Pulse in a public GitLab repository allows users to communicate, collaborate, and contribute to the development of the software. This approach also provides transparency and trust as anyone can view and comment on changes to the code base.

Build and Release Management System

Configuring and managing the build process of a project with multiple target platforms is a challenging task in software development. The Pulse build process is reliant on CMake [49], an open-source tool that manages the build process in a platform- and compiler-independent manner.

Git provides the ability to tag a certain version of the code as a release. As new features are completed, tested, and validated, the Pulse team will add a version tag to the repository that will allow users pull a completed version of the engine that has passed the rigorous testing process. Release information is posted on the Pulse documentation site (

Verification and Validation Suite

Verification and validation are critical to maintaining the quality of open-source software. Pulse provides a comprehensive set of unit tests for all of the algorithms provided by the common software framework, including the circuit solver and substance transport algorithm. It is imperative that these fundamental algorithms are tested to provide the necessary foundation for our physics-based models.

The majority of testing for the Pulse engine is completed via scenario integration tests. A scenario is a predetermined set of actions over time and a set of requested system and compartment outputs. Each of the validation scenarios/cases used to validate the models and behavior of the engine must be tested to ensure the validated results are maintained when changes are implemented in the software. The validated results are used as a baseline “gold standard” set of results. The Pulse test suite can read in a set of ~ 70 scenarios and execute them in parallel Pulse engines to output a file of comma separated values (CSV) of the requested outputs for every time step for every scenario. This suite of scenarios is executed prior to accepting a pull request of a contributor wanting to add their modification to the Pulse GitLab repository. The test suite automatically compares the resulting CSV files to the gold standard results. If the results vary by more than 2%, a flag is set noting a scenario failure. All scenario failures or deviations are reviewed by the Pulse software team to determine if the changes are acceptable, resulting in a new gold standard file, or not. The test suite is downloaded as part of the Pulse build process and instructions for use are provided in the documentation.

Hardware Integration

Many simulation technologies that use or plan to use the Pulse Physiology Engine execute on single-board computers (SBCs) that can be portable and small for optimal interation in their simulation framework. The Pulse software was tested on a variety of these systems to ensure that real-time execution of the physiology could be achieved. Boards using an ARM Cortex-A series core were tested, including a BeagleBone Black, ASUS Tinker Board, ODROID XU4 with both an A15 and A7 processor, Raspberry Pi 3B, Dragonboard 410c, and a Firefly RK3399. The Pulse engine was compiled on each board, and a basic scenario was executed. The run time for 10 s of simulation time was recorded for each test.


Pulse Physiology Engine

Model Validation

For the healthy (baseline) system models, both compartment level (pressure, flow, and volume for each organ or region of interest) and clinical system level values (heart rate, respiratory rate, cardiac output, tidal volume, and oxygen saturation) are validated by comparing to published values in the literature. The healthy models are quantitatively validated, and the error is reported using a good (< 10%), fair (10–30%), poor (> 30%) scale. An example of the reported charts associated with the adult cardiovascular and respiratory systems can be found in [50, 51]. Similarly, the injury, disease, and treatment models are quantitatively validated at the system level, but not the compartment level because of a lack of available data at this level.

Feedback Mechanisms—Baroreceptors

The lumped-parameter models were executed for a basic hemorrhage scenario. After 30 s, a hemorrhage was simulated at 1000 mL/s for 30 s. The loss of 500 mL of blood causes the blood pressure to drop, which triggers the baroreflex response. The systemic vascular resistance and cardiac output increase to drive up the blood pressure, as shown in Fig. 4. This matches the expected trends for a hemorrhage and baroreflex response [35, 52].
Fig. 4

The baroreceptor response increases systemic vascular resistance in response to low blood pressure causing an increase in heart rate and blood pressure

Pharmacokinetic/Pharmacodynamic Models

The PK/PD response for over ten drugs was validated using data from the literature. The calculated plasma concentration was compared to experimental plasma concentration found in the literature. The comparison was completed across several hours of simulation time for each drug, example results for Fentanyl and Ketamine are shown in Fig. 5. The drugs were validated using data found in [53, 54]. The physiologic response to the drugs was also validated for each of the drugs. The body’s response to the drug was validated by comparing to data found in the literature. One example of the calculation after a morphine injection is shown in Fig. 5. This matches the expected trends as found in [55].
Fig. 5

The pharmacokinetic model is validated by comparing the calculated plasma/venous concentration to experimental data for each drug. The pharmacodynamic model is validated by comparing the calculated physiologic outputs to data from the literature. For morphine, the expected moderate drop in respiration rate and the mild drop in heart rate and blood rate are observed

Hardware Integration

The results for the SBC simulation time are shown in Table 6. Only the BeagleBone Black was unable to complete the simulation faster than real time.
Table 6

Benchmark statistics for single-board computers


ARM architecture

# Cores

Processor clock speed


Average time to simulate 10 s

BeagleBone Black

A8 (ARMv7-A)


1 GHz

512 MB

30.75 s


A15/A7 (ARMv7-A)


2/1.3 GHz

2 GB

3.38 s

ASUS Tinker Board

A17 (ARMv7-A)


1.8 GHz

2 GB

3.82 s

Raspberry Pi 3B

A53 (ARMv8-A)


1.2 GHz

1 GB

8.75 s

DragonBoard 410c

A53 (ARMv8-A)


1.2 GHz

1 GB

7.85 s

Firefly RK 3399

A72/A53 (ARMv8-A)


2/2 GHz

2 GB

3.35 s

Case Studies—Community Adoption

Eshelman School of Pharmacy—nXhuman

The University of North Carolina Eshelman School of Pharmacy has embarked on a project to develop a transformative, cutting-edge technology platform for virtual patients (Fig. 6). The intent is to accelerate students’ abilities to manage real-world patient care, from pharmacologic and therapeutic knowledge to clinical decision-making and patient interaction skills. The project, labeled nXhuman and funded by the Eshelman Institute for Innovation, relies on research-based best practices and thus seeks to involve the most recent innovative, openly available tools as its intelligence core. For modeling patient physiology, UNC has selected the Pulse Physiology Engine.
Fig. 6

nXhuman is an innovative and powerful platform that leverages the Pulse Physiology Engine to improve clinical decision-making

nXhuman allows for complex parameters to be programmed into each virtual patient (e.g., disease state, pathophysiology, environmental influences, and lifestyle choices) and also for showing how these patients present over time based on disease progression, age, course of therapy, and adherence to treatment. A robust but adaptable physiology engine is thus critical to the successful use of the platform. Outcomes may occur at multiple levels depending on the scenario, including clinical outcomes (e.g., cure, clinical events, death), physiologic outcomes (e.g., blood pressure, heart rate), and biochemical outcomes (e.g., cholesterol levels). nXhuman scenarios are progressive, so that clinical decisions require increasingly complex reasoning as students gain knowledge and practice skills. The platform facilitates analytics and reporting on student performance, thereby identifying gaps in knowledge and demonstrating changes in application of skills.


The Virtual Pediatric Airway Workbench (VPAW) is a surgical planning tool for subglottic stenosis that incorporates three major components [56]. First, VPAW initiates with a CT scan of the patient and obtains a geometrical model through segmentation and surface reconstruction. Second, it employs a computational fluid dynamics (CFD) engine based on a Lattice–Boltzmann formulation, where fluid is modeled as particles traveling in discrete directions. Exchanges of momentum and energy occur during collisions between particles and the boundary. This formulation is used to compute the airflow in the nasal cavity. Finally, it also provides real-time geometric authoring tools that allow surgeons to edit the tracheal geometry using a haptic device as part of the surgical planning. As a proof of concept, the open-source physiology engine was interfaced with VPAW [57]. The respiratory system of the physiology engine is linked to the CFD model in VPAW via the tracheal resistance in the lumped-parameter model. By calculating the respiration and oxygen saturation due to the stenosis, surgical planning can determine the optimal treatment for the overall physiologic health of the patient. This not only shows a strong proof of concept, but also exposes the possibilities and opportunities in advancing patient-specific surgical planning factoring in individualized physiology.

Pulse Explorer

Kitware has developed a new visualization tool built on the ParaView platform to use and display the results of the Pulse Physiology Engine. The Pulse Physiology Engine Explorer allows the user to execute the anaphylaxis demo by beginning the simulation with a healthy patient. Anaphylaxis is then simulated by applying an airway obstruction that represents the blocked airways caused by swelling. The tidal volume drops due to a lack of airflow into the lungs. The lack of oxygen leads to falling oxygen saturation levels. This is visualized both through plotting the information and changing the color of the lungs to represent the change from pink healthy oxygenated lungs to blue oxygen-deprived tissue. Epinephrine is then administered to the patient in the scenario. The vital signs rapidly recover in response to the drug. This is shown in the plots and the return of the healthy pink tone of the lungs. This demo (Fig. 7) shows one example the physiologic modeling capabilities of the engine and the meaningful information that can be communicated via the Explorer. Kitware plans further development of both the Pulse Physiology Engine and the Explorer to advance patient-specific modeling, training applications, and clinical applications using physiologic models
Fig. 7

The Pulse Physiology Engine Explorer provides an innovative interface to interact with Pulse simulations and outputs


Closed-Loop Physiology Management System

Bucknell University has integrated the Pulse Physiology Engine into a system for investigating closed-loop physiology management for critical care. The closed-loop systems being investigated, known as Closed-Loop Assistants (CLAs) are designed to leverage medical device interfaces to add computers/algorithms to the clinical care loop to aid in decision-making and to implement the automatic application of interventions. CLAs are intended to help clinicians manage the cognitive load that can arise as the complexity of patient management increases. By incorporating patient physiology into the testbed, it is possible to perform early testing and validation of proposed interventions across a small patient population [58]. This collaboration will further develop a patent population that can be used for further testing of the inter- and intra-patient variability found in the initial studies.

Ventriculoperitoneal Shunt Performance

The University of Tennessee, Knoxville is developing a high-fidelity computational surrogate head model focused on the ventricular system to optimize the performance of ventriculoperitoneal shunts. This cutting-edge simulation, funded through a National Institute of Health (NIH) R15 grant, captures complex cerebrospinal (CSF) flow behavior, such as pulsation and transient effects induced by the opening and closing of the shunt valve, to better understand the mechanisms of occlusion and shunt failure. Flexibility to vary the location of ventricular catheter insertion coupled with advanced CFD methodology enables an unprecedented capability to explore the influence of shunting on intracranial pressure (ICP) and CSF circulation.

As well established by the Monro–Kellie hypothesis [59, 60, 61, 62, 63], ICP is a function of the volumes of brain tissue, CSF, and blood inside the fixed space defined by the skull. To revolutionize this research, the CSF model is being coupled with the cerebrovascular system using the Pulse Physiology Platform. Through the addition of a pressure component to the current three element Windkessel model of the cerebrovasculature, multi-scale evaluation of ICP will enable investigation of transient (i.e., elevated heart rate) and disease-state (i.e., high blood pressure) physiological conditions on shunt performance. In addition to globally quantifying the essential cerebrovascular parameters for the local high-fidelity analysis of shunt function, the Pulse Physiology Platform also provides an invaluable training capability to teach students about the effects of elevated ICP due to hydrocephalus on the entire body.


The scope of the Pulse community includes physiologic modelers and software and hardware developers that integrate Pulse into their own systems. To support this community, Pulse provides fully documented models, including the methodology, validation, and supporting data, and clear instructions on how the software can be used and integrated by third parties. Also provided is in depth documentation exploring all aspects of the design and implementation of the Pulse architecture, including system methodology, the common physiology interface, and the logical model description. These details can be found at

Communication is essential for the community to understand, trust, and adopt the Pulse engine for their applications. Quick and helpful responses to questions and issues are a key to supporting an open community of users. Pulse provides multiple forums for end users to learn about new features and ask questions to the Pulse team, including a forum, blog, wiki, issue tracker, and email.

Community users have successfully contributed changes to help build and execute Pulse on new target platforms, such as various aarch64 microprocessors. Users can submit pull requests that address issues and improvements for the software. Execution of the test suite is encouraged prior to submitting a pull request. For help in submitting new models into the engine, including completing documentation, providing validation scenarios, and data, and ensuring verification of existing scenarios due to changes in models, please contact the pulse team (


Medical simulation is an important and growing segment that has proven to be highly effective [2, 8, 64, 65, 66]. However, the development of training content and the purchase of expensive manikin hardware can be cost prohibitive. By providing a robust, stable, well-validated set of physiology models, the ability to develop lower cost alternatives that provide high value training is greatly enhanced. The Pulse framework and architecture provide a means to rapidly expand the modeling content, maintain a well-validated set of models, and support a growing community through software management, testing, and documentation. External contributions from collaborators can also be incorporated, while maintaining the high software standards and practices established for the Pulse open-source project. This will lead to the continued acceptance and integration into commercial and research products.

All of the software is freely available for download and can be used free of charge for commercial and research applications under the Apache 2.0 license. More information can be found at, and the source code is available at The Pulse Physiology Explorer source code is also available for download and can be used free of charge for commercial and research applications. The source code is available at



We would like to thank our early team that worked on the BioGears engine, the precursor to Pulse. We would also like to thank our collaborators on the Case Studies, including Jared Vicory and Cory Qualmann of Kitware, Lucas Potter of Old Dominion University, Michael Messer, James Tiller, Jr., Heidi Jansje Collins, and Catherine MacAllister of the University of North Carolina—Chapel Hill, and Farooq Gessa of Bucknell University. We would also like to thank Matt Pang of Entropic for his contribution to repository for compiling on ARM systems.

Funding information

Initial work on the BioGears Engine (Pulse is a fork of BioGears) was funded by the US Army Medical Research and Materiel Command and administered by the Telemedicine and Advanced Technology Research Center (TATRC), Fort Detrick, MD under contract number W81XWH-13-2-0068.

Compliance with Ethical Standards

Conflict of Interest

The authors declare that they have no conflicts of interest.


  1. 1.
    Committee on Pediatric Emergency Medicine. Patient safety in the pediatric emergency care setting. Pediatrics. 2007;120(6):1367–75.Google Scholar
  2. 2.
    Henneman EA, Cunningham H. Using clinical simulation to teach patient safety in an acute/critical care nursing course. Nurse Educ. 2005;30(4):172–7.CrossRefGoogle Scholar
  3. 3.
    Holcomb JB, et al. Evaluation of trauma team performance using an advanced human patient simulator for resuscitation training. J Trauma. 2002;52(6):1076–8.CrossRefGoogle Scholar
  4. 4.
    Lai F, Entin E, Dierks M, Raemer D, Simon R. Designing simulation-based training scenarios for emergency medical first responders. Proc Hum Factors Ergon Soc Annu Meet. 2004;48(15):1670–4.CrossRefGoogle Scholar
  5. 5.
    Ricks J, Commander NTTC, Medical Simulation for Trauma Care. Combat and Casualty Care ( 2016 :16–17.
  6. 6.
    Calkins MAJMD, Robinson LTTD. Combat trauma airway management: endotracheal intubation versus laryngeal mask airway versus combitube use by Navy SEAL and Reconnaissance combat corpsmen. J Trauma Acute Care Surg. 1999;46(5):927–32.CrossRefGoogle Scholar
  7. 7.
    Barela TP. Mannequins help inprove casualty care. Hurlburt Field: US Air Force News; 2006.Google Scholar
  8. 8.
    Steadman RH, Coates WC, Huang YM, Matevosian R, Larmon BR, McCullough L, et al. Simulation-based training is superior to problem-based learning for the acquisition of critical assessment and management skills. Crit Care Med. 2006;34(1):151–7.Google Scholar
  9. 9.
    Adler MD, Trainor JL, Siddall VJ, McGaghie WC. Development and evaluation of high-fidelity simulation case scenarios for pediatric resident education. Ambul Pediatr. 2007;7(2):182–6.CrossRefGoogle Scholar
  10. 10.
    Eppich WJ, Adler MD, McGaghie WC. Emergency and critical care pediatrics: use of medical simulation for training in acute pediatric emergencies. Curr Opin Pediatr. 2006;18(3):266–71.CrossRefGoogle Scholar
  11. 11.
    Fehr JJ, Boulet JR, Waldrop WB, Snider R, Brockel M, Murray DJ. Simulation-based assessment of pediatric anesthesia skills. Anesthesiology: J Am Soc Anesthesiol. 2011;115(6):1308–15.Google Scholar
  12. 12.
    “Pulse Physiology Engine.” [Online]. Available: [Accessed: 07-Aug-2017].
  13. 13.
    “Welcome to BioGears!” [Online]. Available: [Accessed: 07-Aug-2017].
  14. 14.
    Hester R, Brown A, Husband L, Iliescu R, Pruett WA, Summers RL, et al. HumMod: a modeling environment for the simulation of integrative human physiology. Front Physiol. 2011;2:12.Google Scholar
  15. 15.
    “CAE Healthcare.” [Online]. Available: [Accessed: 07-Aug-2017].
  16. 16.
    “HumMod | The best, most complete, mathematical model of human physiology ever created.” [Online]. Available: [Accessed: 07-Aug-2017].
  17. 17.
    Brown R, McIlwain S, Willson B, Hackett M. Enhancing Combat Medic training with 3D virtual environments. In: 2016 IEEE International Conference on Serious Games and Applications for Health (SeGAH). IEEE; 2016. pp. 1–7.Google Scholar
  18. 18.
    Clipp RB, Scott G HumanSim: a physiology engine for the simulation of anesthesia/anaphylaxis training. in Military Health Research symposium 2012, 2012.Google Scholar
  19. 19.
    Lerant AA, Hester RL, Coleman TG, Phillips WJ, Orledge JD, Murray WB. Preventing and treating hypoxia: using a physiology simulator to demonstrate the value of pre-oxygenation and the futility of hyperventilation. Int J Med Sci. 2015;12(8):625–32.CrossRefGoogle Scholar
  20. 20.
    “CAE PediaSim.” [Online]. Available: [Accessed: 18-Jul-2017].
  21. 21.
    “SimVascular.” [Online]. Available: [Accessed: 05-Dec-2017].
  22. 22.
    “SimTK: OpenSim: Project Home.” [Online]. Available: [Accessed: 05-Dec-2017].
  23. 23.
    Abdi M, Karimi A, Navidbakhsh M, Pirzad Jahromi G, Hassani K. A lumped parameter mathematical model to analyze the effects of tachycardia and bradycardia on the cardiovascular system. Int J Numer Model Electron Networks, Devices Fields. 2015;28(3):346–57.CrossRefGoogle Scholar
  24. 24.
    Liang F, Liu H. A closed-loop lumped parameter computational model for human cardiovascular system. JSME Int J Ser C Mech Syst Mach Elem Manuf. 2005;48(4):484–93.Google Scholar
  25. 25.
    Liang F, Liu H. A closed-loop lumped parameter computational model for human cardiovascular system. JSME Int J Ser C Mech Syst Mach Elem Manuf. 2005;48(4):484–93.CrossRefGoogle Scholar
  26. 26.
    Olufsen MS, Nadim A. On deriving lumped models for blood flow and pressure in the systemic arteries. Math Biosci Eng. 2004;1(1):61–80.CrossRefGoogle Scholar
  27. 27.
    Segers P, Stergiopulos N, Westerhof N, Wouters P, Kolh P, Verdonck P. Systemic and pulmonary hemodynamics assessed with a lumped-parameter heart-arterial interaction model. J Eng Math. 2003;47(3/4):185–99.CrossRefGoogle Scholar
  28. 28.
    Shim EB, Sah JY, Youn CH. Mathematical modeling of cardiovascular system dynamics using a lumped parameter method. Jpn J Physiol. 2004;54(54):545–53.CrossRefGoogle Scholar
  29. 29.
    Abram SR, Hodnett BL, Summers RL, Coleman TG, Hester RL. Quantitative Circulatory Physiology: an integrative mathematical model of human physiology for medical education. Adv Physiol Educ. 2007;31(2):202–10.Google Scholar
  30. 30.
    Hester R, Summers R, Iliescu R, Coleman T. HumMod: An integrative model of integrative biomedicine. Orlando: I/ITSEC; 2010.Google Scholar
  31. 31.
    Gebremichael Y et al. Integration of a spontaneous respiratory driver with blood gas feedback into BioGears, an apen-source, whole-body physiology model. In: Summer Biomechanics, Bioengineering, and Biotransport Conference, 2015.Google Scholar
  32. 32.
    Swarm ZM et al. Modeling renal behavior and control in BioGears. In: Medicine meets virtual reality conference, 2016.Google Scholar
  33. 33.
    Enquobahrie A, et al. The image-guided surgery toolkit IGSTK: an open source C++ software toolkit. J Digit Imaging. 2007;20(Suppl 1):21–33.CrossRefGoogle Scholar
  34. 34.
    Olufsen MS, Nadim A, Lipsitz LA. Dynamics of cerebral blood flow regulation explained using a lumped parameter model. Am J Phys Regul Integr Comp Phys. 2002;282(2):R611–22.Google Scholar
  35. 35.
    Ottesen J, Olufsen M, Larsen J. Applied mathematical models in human physiology. Denmark: Roskilde University; 2006.Google Scholar
  36. 36.
    Clipp RB et al. Integration of a baroreflex model into a whole body physiology engine. In: Summer Biomechanics, Bioengineering, and Biotransport Conference, 2016.Google Scholar
  37. 37.
    Khalil F, Läer S. Physiologically based pharmacokinetic modeling: methodology, applications, and limitations with a focus on its role in pediatric drug development. J Biomed Biotechnol. 2011;2011:907461.CrossRefGoogle Scholar
  38. 38.
    Metoyer R et al. Multiscale simulation of insults and interventions: the BioGears showcase scenarios. In: Medicine meets virtual reality conference, 2016.Google Scholar
  39. 39.
    Rodgers T, Leahy D, Rowland M. Physiologically based pharmacokinetic modeling 1: predicting the tissue distribution of moderate-to-strong bases. J Pharm Sci. 2005;94(6):1259–76.CrossRefGoogle Scholar
  40. 40.
    Rodgers T, Rowland M. Physiologically based pharmacokinetic modelling 2: predicting the tissue distribution of acids, very weak bases, neutrals and zwitterions. J Pharm Sci. 2006;95(6):1238–57.CrossRefGoogle Scholar
  41. 41.
    Huisinga W, Solms A, Fronton L, Pilari S. Modeling interindividual variability in physiologically based pharmacokinetics and its link to mechanistic covariate modeling. CPT Pharmacometrics Syst Pharmacol. 2012;1(September):e4.CrossRefGoogle Scholar
  42. 42.
    Valentin J. Basic anatomical and physiological data for use in radiological protection: reference values. Ann ICRP. 2012;32(3–4):1–277.Google Scholar
  43. 43.
    Rosenbaum SE, editor. Basic pharmacokinetics and pharmacodynamics: An integrated textbook and computer simulations: John Wiley & Sons; 2016.Google Scholar
  44. 44.
    Vladimirescu A. The SPICE book: John Wiley & Sons, Inc.; 1994.Google Scholar
  45. 45.
    “ngSPICE.” [Online]. Available:
  46. 46.
    Riggs DS. Control theory and physiological feedback mechanisms. Huntington: Robert E. Krieger Publishing Company; 1976.Google Scholar
  47. 47.
    Chung-Wen H, Ruehli A, Brennan P. The modified nodal approach to network analysis. IEEE Trans Circuits Syst. 1975;22(6):504–9.CrossRefGoogle Scholar
  48. 48.
    Nic M, Jirat J, Kosata AJ, McNaught A. IUPAC compendium of chemical terminology. Research Triangle Park, NC, 2009.Google Scholar
  49. 49.
    Martin K, Hoffman B. Mastering CMake version 3.1. Kitware Inc, 2015.Google Scholar
  50. 50.
    “Respiratory Methodology.” [Online]. Available: [Accessed: 26-Sep-2017].
  51. 51.
    “Cardiovascular Methodology.” [Online]. Available: [Accessed: 26-Sep-2017].
  52. 52.
    Hosomi H, Sagawa K. Effect of pentobarbital anesthesia on hypotension after 10% hemorrhage in the dog. Am J Phys. 1979;236(4):H607–12.Google Scholar
  53. 53.
    Xie H, Wang X, Liu G, Wang G. Analgesic effects and pharmacokinetics of a low dose of ketamine preoperatively administered epidurally or intravenously. Clin J Pain. 2003;19(5):317–22.CrossRefGoogle Scholar
  54. 54.
    Shankaran H, Adeshina F, Teeguarden JG. Physiologically-based pharmacokinetic model for fentanyl in support of the development of provisional advisory levels. Toxicol Appl Pharmacol. 2013;273(3):464–76.CrossRefGoogle Scholar
  55. 55.
    Murray MJ, Edward Morgan G Jr., Mikhail MS. Clinical Anesthesiology. Lange Medical. 4th ed. Books/McGraw-Hill; 2006.Google Scholar
  56. 56.
    Quammen CW, et al. The virtual pediatric airways workbench. Stud Health Technol Inform. 2016;220:295–300.Google Scholar
  57. 57.
    Potter L, Arikatla S, Bray A, Webb J, Enquobahrie A. Physiology informed virtual surgical planning: a case study with a virtual airway surgical planner and BioGears. In: Medical Imaging 2017: Image-Guided Procedures, Robotic Interventions, and Modeling (Vol. 10135). International Society for Optics and Photonics; 2017. p. 101351T.Google Scholar
  58. 58.
    Gessa F, Asare P, Clipp RB, Bray A, Poler M. Towards a test and validation framework for closed-loop physiology management systems for critical and perioperative care. Medical cyber physical systems workshop, 2018. Cyber-Physical Systems Week 2018. Porto, Portugal.Google Scholar
  59. 59.
    Gilkes CE, Whitfield PC. Intracranial pressure and cerebral blood flow. Surgery. 2007;25(12):530–5.Google Scholar
  60. 60.
    Lee HS, Yoon SH. Hypothesis for lateral ventricular dilatation in communicating hydrocephalus: New understanding of the Monro-Kellie hypothesis in the aspect of cardiac energy transfer through arterial blood flow. Med Hypotheses. 2009;72(2):174–7.Google Scholar
  61. 61.
    Oswal A, Toma AK. Intracranial pressure and cerebral haemodynamics. Anaesth Intensive Care Med. 2017;18(5):259–63.CrossRefGoogle Scholar
  62. 62.
    Partington T, Farmery A. Intracranial pressure and cerebral blood flow. Anaesth Intensive Care Med. 2014;15(4):189–94.CrossRefGoogle Scholar
  63. 63.
    Shardlow E, Jackson A. Cerebral blood flow and intracranial pressure. Anaesth Intensive Care Med. 2011;12(5):220–3.CrossRefGoogle Scholar
  64. 64.
    Kovatchev BP, Breton M, Dalla Man C, Cobelli C. In silico preclinical trials: a proof of concept in closed-loop control of type 1 diabetes. 2009: 44–55.Google Scholar
  65. 65.
    Jiang Z, Pajic M, Connolly A, Dixit S, Mangharam R. Real-time heart model for implantable cardiac device validation and verification. In: 2010 22nd Euromicro Conference on Real-Time Systems. IEEE; 2010. p. 239–48.Google Scholar
  66. 66.
    Bauman EB. Game-based teaching and simulation in nursing and health care. New York: Springer Publishing Company, LLC; 2013.Google Scholar

Copyright information

© Springer Nature Switzerland AG 2019

Authors and Affiliations

  1. 1.Kitware, IncCarrboroUSA
  2. 2.University of North CarolinaChapel HillUSA
  3. 3.University of TennesseeKnoxvilleUSA
  4. 4.Bucknell UniversityLewisburgUSA

Personalised recommendations