1

Agenda (1:30pm – 5:00 pm)

1. Engine Overview [~50min]

• Bio Break [10min]

2. Using the Graphical User Interface (GUI) [~50min]

• Bio Break [10min]

3. Interacting with the Application Program Interface (API) [~50min]

4. Questions and Help [until 5pm]

Recommended Preparation

• If you would like to follow along using the GUI (item 2), please download and unzip the Toolkit from: https://biogearsengine.com/download

BioGears: An OpenSource Human Physiology Engine

2

Presentation for MMVR

Presenters: Jeff Webb, Rachel Clipp, PhD, Aaron Bray

Applied Research Associates, Inc. (ARA)

7 April 2016

BioGears Overview

3

• Program Overview

• Modeling Approach

• Verification and Validation

• Systems Review

• Architecture and Tools

• Coming Soon

BioGears Overview Agenda

4

PROGRAM OVERVIEW

5

• Organization: Applied Research Associates, Inc. (ARA)

• Telemedicine & Advanced Technology Research Center (TATRC)

Award #: W81XWH-13-2-0068

• Principal Investigator: Mr. Jeff Webb

• Amount: $6,959,593

• Period of Performance: Sept 2013 – Sept 2018

• License: Apache 2.0 permissive free software

• Disclaimer: This work is supported by the US Army Medical Research and

Materiel Command. The views, opinions and/or findings contained in this report are

those of the author(s) and should not be construed as an official Department of the

Army position, policy, or decision unless so designated by other documentation.

Project Information

6

High Level Objectives

• Create a publicly available physiology research platform that enables accurate and consistent simulated physiology across training applications

• Lower the barrier to create medical training content

• Engage the community to develop and extend physiology models

• Meet the training needs of the military

• Expand the body of knowledge regarding the use of simulated physiology for medical education

7

Organs & Tissues

Extravascular & Intravascular

Homeostatic Feedback

• Baroreceptors & Osmoreceptors

• Chemoreceptors

• Local Autoregulation

Physics Based Approach

• Fluid Mechanics – Gases & Fluids

• Thermodynamics – Heat Transfer

Substances

Transport, Diffusion, & Clearance

• Gases

• Hemoglobin

• Ions

Patients External Systems

Internal Systems

Equipment

Features

Inputs

• Parameter Setting

• Chronic Conditions

• Insults

• Interventions

Outputs

• Acute Events

• Clinical Assessments

• System Vitals

• Compartment Data

Scenarios

• Static and Repeatable

and/or

• Real-Time Dynamic

Personalized

Configuration

Interfaces

Drugs

PK/PD

Environment

Substances & Thermal

Nervous

Sympathetic & Parasym.

Anesthesia

Machine

Inhaler

System Interactions

Cardiovascular

Hemodynamics & ECG

Respiratory

Gas Exchange

Blood Chemistry

Quantities & Panels

Renal

Blood Filtering

Endocrine

Hormones

Gastrointestinal

Ingestion

Energy

Thermal & Metabolic • Hormones

• Nutrients

• Drugs

Physiology Engine Overview

8

Milestones

2015

Link to Version History

FY13 September: project kick-off

FY14

FY15October: Alpha Build 1.0.0 release and website launchMarch: 2.0.0 releaseJuly: 3.0.0 release

FY16

October: Beta Build 4.0.0 release and users conferenceDecember: 5.0.0 releaseMarch: 5.1.0 release

Summer: planned Release Candidate 6.0.0• System updates• Serialization, modularity, and optimization

FY17Several releases throughout• New systems/features

FY18October: Final Contractual releaseMaintenance only

We are here

9

Current Collaborators and Integrators• 2,700+ downloads of the engine and related files since the Alpha Build Release

(October 2014)

• 1,400+ pages of physiology modeling methodology and software documentation, and validation data available to our user community

• Used by the government/military, academic institutions, and commercial businesses

• Let us know if/when you use BioGears and we can add you to the home page of our website!

10

MODELING APPROACH

11

Engine Overview

Computation Approach:• Time-stepping transient analysis for linearization of differential equations

• Currently 90Hz for 2x real-time simulation on standard laptops

• Dynamically change/add/remove elements to represent physiological mechanisms

• Stabilization analysis for initialization and implementation of conditions

• Designed with low computational overhead

• Faster than real-time on typical PC, multiple instances on single or multicore processors

• Build Targets include Windows, Mac, Linux, and Raspberry Pi

Modeling Approach:

• Top-down approach to model development with bottom-up hooks for engine expansion

• Multi-scale for varying fidelity, allowing integration of models from any level

12

• Discrete entities that approximate the behavior of a distributed system

• Electronic-Hydraulic/Thermal Analogy: body system fluid dynamics and thermodynamics modeled using electrical circuit math

• Generalized definitions of Nodes, Paths, and Elements for simple understanding, implementation, and modification

Background: Lumped Parameter Modeling

Lumped Parameter Modeling of Fluids

P=Pressure, F=Flow, R=Resistance, C=Compliance, I=Inertance

13

• Data model• Generic and reusable node and path definitions

• Uses the same equations/code with native units

• Other element types not in table:• Switch

• Valve/diode

• Polarized elements

Lumped Parameter Approach

Circuit Types and Elements

Definitions

14

Connection types:

• Direct circuit connection – e.g. Anesthesia Machine and Respiratory

• Feedback – e.g. Nervous and Endocrine

• Substance exchange – e.g. Respiratory and Cardiovascular gas exchange

Physiology System Interaction

EnvironmentPK/PD

Cardiovascular

Blood

Tissue

Extravascular

Respiratory

Anesthesia Machine

Renal

Gastrointestinal

Energy

Nervous

Endocrine

Inhaler

15

System Data Flow and Modeling

Approach Advantages

• Modular and extensible

• Model fidelity easily modified by adding/removing nodes and elements to circuit

• Fully dynamic physics based mechanistic models (rather than state based) – cascading effects

• Unlimited stacking/combining of conditions, insults, interventions, interfaces, etc.

• Homeostasis based modeling with pathophysiology actions

• Able to integrate existing/new models

• Not necessarily lumped parameter

• Mixed fidelity

• Able to simultaneously run any number of instances/patients

PreprocessUses feedback mechanisms to modify elements for the next time step.

ProcessCalculates the entire state of the system for the next time step

AssessmentsCalled on demand to calculate and set assessment specific data

ResetInitializes the system

InitializationResting: Functionality specific to resting patient stabilization

Conditions: Functionality specific to applying conditions

PostProcessAdvances time by moving the next time step to current

16

Engine Initialization

Resting Conditions Running

Stabilization Simulation

Time = 0

• Dynamic stabilization drives towards patient homeostasis

• Each step the engine executes until all specified stabilization criteria are satisfied

Step 1: Patient initialization• Systems feedback

modifies values to achieve specified patient parameters (e.g. baseline mean arterial pressure)

• Standard environment used

Step 2: Condition initialization• Conditions applied

to represent new patient homeostatic state

• Environment changes applied to simulate long term acclimation

Simulation begins• Acute insults,

interventions, and parameter modification applied instantaneously through actions

Step 3: Feedback Mechanisms• Feedback

mechanisms that would interfere with chronic conditions (e.g. baroreceptors) are activated

Feedback

17

Engine Data Library

Tidal Volume varies with

weight

Circuit is modified to

vary arterial pressure

Driver is modified to vary

heart rate

1

2 3

Patient File Parameters

Gender FunctionalResidualCapacity

Age 2: HeartRateBasline

1: Weight 3: MeanArterialPressureBaseline

Height RespirationRateBaseline

BodyFatFraction RightLungRatio

CarinaToTeethDistance TotalBloodVolumeBaseline

Contractility

Patient Modification Example

Patients

• Properties modify system setup, circuit values, and feedback parameters

Substances

• Physical and transport related properties

• E.g. MolarMass, IonicState, Sedation

Compounds

• Concentrations of multiple substances

• E.g. Saline, Blood

Environments

• Surrounding properties

• E.g. AmbientTemperature, ClothingResistance

Nutrition

• Meal composition (masses)

• E.g. Protein, Calcium

Stabilization

• Percent difference criteria for stabilization – resting and conditions

18

• Anatomical Compartments defined by sub-circuits and allow access via an anatomy tree

• Several overlapping compartment types• Fluid

• Liquid• Vascular

• Urine

• Chyme

• Gas• Pulmonary

• Tissue

• Thermal

• Electrical

• Compartment properties are combined from children (liquid example)

• Volume is a sum

• InFlow is a sum

• OutFlow is a sum

• Pressure comes from an assigned child node (sum does not make sense)

• Substance quantities (mass, concentration, etc.) are calculated on demand for any level in hierarchy

• There are thousands of compartment data values that are updated each time-step

Left Kidney

Left Renal Artery

Left Renal Vein

Left Nephron

Left Afferent Arteriole

Left Glomerular Capillaries

Left Efferent Arteriole

Left Peritubular Capillaries

Left Bowmans Capsules

Left Tubules

Left Ureter

Compartment Example: Kidney Definition

Key:

Vascular

Urine

19

VERIFICATION AND

VALIDATION

20

1. Full Scenario Suite: BioGears test suite includes scenarios to test all patient files, patient actions, substance effects, and equipment performance. Completed for 3 circuit unit tests and 80+ scenarios.

2. Circuit Verification: Verify that the BioGears circuit solver is producing comparable results to established circuit solvers. Completed for 100+ circuit elements/combinations.

3. Timing: Suite is executed by team members throughout development. It is also automatically executed when the code base is altered in the repository.

4. Output: Each scenario indicates the physiologic outputs for validation. Each output is tested to ensure it is within 2% of the results in the code repository. Comparison and error plots (shown) are generated.

5. Full Results: An email is sent to all team members when verification is complete. Each scenario either Passes (green) or Fails (red). Failures must be addressed by the team.

Verification

Source of Failure

VentilatorPressureLossScenarioResultsReport 1 1 21.258999824523926

YpieceDisconnectScenarioResultsReport 1 1 23.98900008201599

AirwayInsultObstructionResultsReport 0 1 14.930999994277954

AtropineScenarioResultsReport 0 1 13.121000051498413

BasicScenario1ResultsReport 0 1 18.195000171661377

Scenario Verification

Circuit Verification

21

1. Verification: Unit tests ensure correct implementation and sound physics principles for all tools

2. System Level Validation: All major systems (cardiovascular, respiratory, blood chemistry, etc.) are validated for clinical output level data

3. Compartment Level Calibration: Individual organs (kidney, liver, etc.) or functional units (trachea, alveoli, etc.) are validated wherever possible

4. Scenario Calibration & Validation: Every insult, intervention, and assessment includes a matrix with validation data for whole body combined effects from multiple systems

5. Combined Scenario Validation: All four showcases and several other scenarios validated for combined effects – heavily leveraged SME consultants Bryan Bergeron MD and Nicholas Moss PhD

Showcase Scenario Combined Effects Validation

Calibration and Validation

ScenarioNumber (%) of Validation Measures in Deviation Category

Total< 10% 10 – 30% > 30%

Combat Multitrauma 59 (64.8%) 10 (11.0%) 22 (24.2%) 91

Asthma Attack 26 (65.0%) 7 (17.5%) 7 (17.5%) 40

Heat Stroke 52 (76.5%) 10 (14.7%) 6 (8.8%) 68

Exposure 26 (86.7%) 2 (6.7%) 2 (6.7%) 30

22

SYSTEMS REVIEW

23

Feedback

• Heart driver – variable compliance

Actions

• Cardiac Arrest

• CPR

• Hemorrhage

• Pericardial Effusion

Conditions

• Anemia

• Arrhythmia

• Bradycardia

• Tachycardia

• Heart Failure

• Pericardial Effusion

Events

• Asystole

• Bradycardia & Tachycardia

• Cardiac Arrest

• Hypovolemic Shock

Assessments

• None

Cardiovascular

Data Type

Number (%) of Validation Measures in

Deviation Category Total

< 10% 10 – 30% > 30%

System 18 (75.0%) 4 (16.7%) 2 (8.3%) 24

Compartment 54 (84.4%) 4 (6.3%) 6 (9.4%) 64

Circuit Diagram

Resting Validation

ECG Outputs

Tachycardia

Bradycardia

Heart Elastance and Compliance

Heart Pressure-Volume Curve

24

Feedback

• Respiratory driver – from aorta O2 and CO2

• Pleural compliance – from lung volume

Actions

• Airway Obstruction

• Bronchoconstriction

• Asthma Attack

• COPD Bronchitis

• Intubation

• Pneumothorax

• Conscious Respiration

• Occlusive Dressing

• Needle Decompression

Conditions

• COPD (Bronchitis and Emphysema)

• Lobar Pneumonia

• Respiratory Acidosis & Alkalosis

• Max Pulmonary Ventilation Rate

• Right Mainstem Intubation

Events

• Bradypnea & Tachypnea

Assessments

• Pulmonary Function Test

Respiratory

Data Type

Number (%) of Validation Measures in

Deviation Category Total

< 10% 10 – 30% > 30%

System 10 (83.3%) 0 (0.0%) 2 (16.7%) 12

Compartment 31 (86.1%) 2 (5.6%) 3 (8.3%) 36

Circuit Diagram

Resting Validation

Lung Volume and Pressures vs Accepted Variable Compliance vs Accepted

25

Feedback

• Ultrafiltration – from substance molecular weight/radius and charge

• Colloid osmotic pressure – from local Albumin concentration

• Tubuloglomerular – from tubules sodium delivery

• Osmoreceptor – from blood osmolarity

• Active and Passive Reabsorption –from ratio to fluid flow

• Gluconeogenesis

• Drug clearance

Actions

• Urinate

Conditions

• Renal Stenosis

Events

• Diuresis & Antidiuresis

• Natriuresis

• Dehydration

• Functional Incontinence

Assessments

• Urinalysis

Renal

Data Type

Number (%) of Validation Measures in

Deviation Category Total

< 10% 10 – 30% > 30%

System 28 (56.0%) 7 (14.0%) 15 (30.0%) 50

Compartment 25 (55.6%) 12 (26.7%) 8 (17.8%) 45

Substance Params 15 (50.0%) 6 (20.0%) 9 (30.0%) 30

Assessment 6 (100.0%) 0 (0.0%) 0 (0.0%) 6

Left Kidney Circuit Diagram

Resting Validation

26

Settings

• Air Density

• Air Velocity

• Ambient Temperature

• Atmospheric Pressure

• Clothing Resistance

• Emissivity

• Mean Radiant Temperature

• Relative Humidity

• Respiration Ambient Temperature

• Ambient Substance

Actions

• Environment Change

• Thermal Application• Active Heating

• Active Cooling

• Applied Temperature

Conditions

• Environment Change

Events

• None

Assessments

• None

EnvironmentCircuit Diagram

Thermoregulation Model

High Altitude Change Scenario Results

27

Feedback

• Thermal feedback on vascular resistance

• Sweating response due to increase core temperature

• Shivering response due to decreased core temperature

• Metabolic effects on Cardiovascular and Respiratory systems during physical activity

Actions

• Exercise

Conditions

• Dehydration

• Starvation

Events

• Fasciculation

• Fatigue

• Hyperthermia

• Heat Stroke

• Metabolic/Respiratory Acidosis & Alkalosis

Assessments

• None

Energy

Data Type

Number (%) of Validation Measures in

Deviation Category Total

< 10% 10 – 30% > 30%

System 9 (100.0%) 0 (0.0%) 0 (0.0%) 9

Circuit Diagram

Resting Validation

Cold Water Submersion Scenario Results

Exercise Submersion Scenario Results

28

Feedback

• PK• Partition

Coefficients

• Clearance

• PD• Drug Effects

Actions

• IV Fluid Administration

• IV Drug Administration

• IM Drug Administration

Conditions

• None

Events

• None

Assessments

• None

DrugsTransport Schematic

Morphine PD Effects

PK Validation

29

Settings

• General• State (on/off)

• Ventilator Pressure

• Respiratory Rate

• Positive End Expired Pressure

• Inspiratory Expiratory Ratio

• Relief Valve Pressure

• Ventilator Pressure

• Oxygen Bottle One Volume

• Oxygen Bottle Two Volume

• Gas Inlet Settings• Inlet Flow

• Oxygen Fraction

• Primary Gas (Nitrogen/Air)

• Oxygen Source (Bottle 1/Bottle 2/Wall)

• Related Settings• Airway Mode (Free/Mask/Tube)

• Substance Administration

Actions

• Expiratory/Inspiratory Valve Leaks/Obstructions

• Soda Lime Failure

• Mask/Tube Leak

• Vaporizer Failure

• Ventilator Pressure Loss

• Oxygen Port/Tank Pressure Loss

• Endotracheal Intubation

• Esophageal Intubation

Conditions

• Environment Change

Events

• Oxygen Bottle Exhausted

• Relief Valve Active

Assessments

• None

Anesthesia Machine

Circuit Diagram

Pressure

Controlled

Model

30

Settings

• Substance

• Metered Dose

• Nozzle Loss

• Spacer Volume

Actions

• Actuation

Conditions

• None

Events

• None

Assessments

• None

Inhaler Circuit Diagram

Albuterol Administration Results

31

Feedback

• Baroreceptors [Nervous]

• Epinephrine and Norepinephrine release [Endocrine]

• Produce Albumin [System Interactions / Hepatic]

• Acid-Base balance (including O2 & CO2 saturation & pH) [System Interactions]

• Gas exchange (Alveolar transfer) [System Interactions]

Actions

• Consume Meal [Gastrointestinal]

Conditions

• None

Events

• Irreversible state

• Hypercapnia & Hypoxia [Blood Chemistry]

• Brain & Myocardium Oxygen Deficit [Blood Chemistry]

Assessments

• Complete Blood Count [Blood Chemistry]

• Comprehensive Metabolic Panel [Blood Chemistry]

Remaining Systems

Data Type

Number (%) of Validation Measures in

Deviation Category Total

< 10% 10 – 30% > 30%

System 37 (84.1%) 2 (4.5%) 5 (11.4%) 44

Patients 85 (100.0%) 0 (0.0%) 0 (0.0%) 85

Assessments 16 (100.0%) 0 (0.0%) 0 (0.0%) 16

Resting Validation

Hemorrhage Scenario Results

32

ARCHITECTURE AND TOOLS

33

• Common Data Model (CDM): Well-defined, intuitive, interchangeable format to standardize interfaces• Standardized inputs, outputs,

units, and naming conventions to aid model additions and external model integrators

• Application Programming Interface (API): Easy integration and interaction in any programming language• Data organized logically by

Anatomy so that users are able to easily find and pull relevant data

• Software Development Kit (SDK): Application examples and stand-alone execution• Tutorials, How-to’s, scenario

examples

Software Architecture

34

• Common data structures for modeling and simulation of the human body

• Not specific to any methodology, including BioGears

• Separates the physiological data from the physiological modeling methodology

• Object Oriented Design of class structures providing a unified set of tools that

promotes fast development, compatible data sets, and well-defined interfaces

• Provides a well-defined data interchange format that disparate models can use

for standardizing inputs and outputs between each other

• Allows for specific extensions, but interfaces are defined by the CDM

Common Data Model Overview

Conceptual Data Model

XSD Schema Files

• Properties.xsd• System.xsd• Substance.xsd• Scenario.xsd• Circuit.xsd• Anatomy.xsd• Patient & Actions.xsd• Equipment & Actions.xsd• BioGears.xsd

Data forms, variables, definitions, and relationships

Data Model Binding

Code Synthesis DLL

• Properties.cxx• System.cxx• Substance.cxx• Scenario.cxx• Circuit.cxx• Anatomy.cxx• Patient & Actions.cxx• Equipment & Actions.cxx• BioGears.cxx

Auto generated C++ Classes-Turnkey Serialization Support

Common Data Model API

C++ DLL

• SEProperty.cpp, SEScalar.cpp, SEScalarVolume.cpp, etc.

• SECardiovascular.cpp, SERespiratory.cpp, etc.

• SECircuit.cpp, SECircuitNode.cpp, SECircuitPath.cpp, etc.

• SEPatient.cpp, SESubstance.cpp, SEDrug.cpp, etc.

• SESubstanceAdministration.cpp, SEHemorrhage.cpp, etc.

Class library reflects the binding and utilizes serialization support

• Unit Conversion • Logging (log4cpp)• Unit Test Framework • Generic Circuit Solver• Generic Circuit Transport • Generic Math • Pure Virtual Physiology Engine

Interface• Scenario Definition and Execution

Additional general algorithms

35

Setup/Modify

Next Values

Modified Nodal

Analysis

Calculate

Fluxes

Valves

Pass?

Set Node

QuantitiesAdvance Time

Modify Valve

States

Yes

No

Calculate

Quantities

Preprocess:

1. Systems use “Current” values to setup/modify “Next”

values via feedback mechanisms (outside of the solver)

Process:

2. Perform numerical integration by using linearization

(first order approximations) through Modified Nodal

Analysis (Ax=b)

a. Use KCL (total Flux at each node = 0) to

Calculate the Jacobian matrix (A) and right-

hand side vector (b) for each Node Potential

and Potential Source Flux (x)

b. Use the Eigen templated library linear solver

(FullPivLU) to solve for x vector

3. Calculate unknown Fluxes – using Trapezoid Rule

where applicable

4. Calculate Valves using assumed diode states (cannot

be solved directly) – iterate as necessary

5. Calculate and increment Compliance Path Quantities

– No other elements have dynamic Quantities (rigid

pipes)

6. Set Node Quantities (based on Path Quantities)

• Note: Transporter is called here

Postprocess:

7. Advance time by moving “Next” to “Current” values

Process

Preprocess

Postprocess

1

2

3

5

67

4

Circuit Solver

• Fully dynamic Modified Nodal Analysis solver for any valid closed-loop circuit

• Solves circuit types with any units: Electrical, Fluid, Thermal

36

• Common Data Model:• Substances move with the fluid to each node

in the circuit

• No particle deposition

• Mass is updated as at each time step based on flow into and out of nodes

• Concentration and partial pressure are updated after the mass

• Systems Interactions:• Partial pressure driven diffusion moves

substances between two nodes (O2, CO2, N2)

• Perfusion limited diffusion moves substances across the blood/tissue barrier based on flow and partition coefficients (Drugs)

• Systemic clearance removes substances from the vena cava to represent metabolic or other clearance mechanisms

• Hepatic clearance removes substances from the liver to represent the ability of the liver to metabolize or remove substances

Transporter

Lung Vascular

Lung Tissue

Heart

Kidney Tissue

Kidney Vascular

Lung Airway

Liver Tissue

Liver Vascular

Other Tissue

Other Vascular

Bladder

GI

37

Motivation

• Data driven developers’ tool to demonstrate basic functionality

• Test Engine without command line

• Ready for testing out-of-the-box (no compiling)

• Simple interface for creating, editing, and executing scenario file, and creating resulting plots of requested data

Expectations

• Only requirements are to allow editing and execution of scenarios – not a major focus

• Not heavily QA’ed – some known bugs being continuously fixed

Limitations

• Clunky Java Swing for rapid prototyping via the API

Developer GUI

38

COMING SOON

39

Current (hopefully deployed this summer with version 6.0.0):

• Bug fixing and system refinement

• Optimization and increased simulation speed

• State serialization – saving and loading simulations

• Modularity – more easily replace entire systems

• Renal feedback updates

• Acid-base balance – O2 & CO2 saturation modifications

• Total body substance balance and new substances

Near-Term (FY16):

• Nervous system additions

• Exocrine additions

• Endocrine additions

• Vascular fluid exchange

• Pneumothorax updates

• Gastrointestinal updates

Long-Term (FY17):

• Patient modifications (gender, body mass, etc)

• Intoxications – Ketamine proof of concept

• Airborne agents (Nerve/Pulmonary/Smoke/CO) and vaporization

• Diuretics

• Additions to blood assessments and pulmonary function test improvement

High Level Near Term Tasks

40

• Use the software for any and all applications (please let us

know)

• Report problems

• Submit code

• Currently just email us

(https://www.biogearsengine.com/workwithus)

• Moving to a public repository – GitHub/BitBucket hosted

• Post and respond to Forums

(https://www.biogearsengine.com/forums)

How to Contribute

41

Please Come See Our Posters!

Showcases: Rodney Metoyer Renal: Dr. Austin Baird

PK/PD: Dr. Rachel Clipp Energy: Cam Thames

42

Jeff Webb

Principal Investigator

jwebb@ara.com

919-582-3435

Rachel Clipp, PhD

Lead Physiology Modeler

rclipp@ara.com

919-582-3330

Aaron Bray

Lead Software Architect

abray@ara.com

919-582-3333

Contact

www.biogearsengine.com/workwithus

43

BACKUP

44

Current System Capabilities

Systems Acute Insults & Interventions Chronic Conditions Events

Cardiovascular& Blood Chemistry

Cardiac ArrestCPRHemorrhagePericardial Effusion

AnemiaArrhythmiaBradycardiaTachycardiaHeart FailurePericardial Effusion

AsystoleBradycardia & TachycardiaBradypnea & TachypneaBrain & Myocardium Oxygen DeficitCardiac ArrestHypercapnia & HypoxiaHyperglycemia & HypoglycemiaHypovolemic ShockPulseless Rhythm

Respiratory Airway ObstructionBronchoconstrictionAsthma AttackCOPD BronchitisIntubation

PneumothoraxConscious RespirationOcclusive DressingNeedle Decompression

COPDLobar Pneumonia

Energy & Environment

ExerciseEnvironment ChangesThermal Application

DehydrationStarvationEnvironment Changes

FasciculationFatigueHyperthermiaHeat StrokeMetabolic/Respiratory Acidosis & Alkalosis

Renal & GI

UrinateConsume Meal

Renal Stenosis Diuresis & AntidiuresisNatriuresisDehydrationFunctional Incontinence

Drugs& Substances& Inhaler

IV Fluid AdministrationIV Drug Administration

IM Drug AdministrationInhaler Drug Administration

Anesthesia Machine ConfigurationExpiratory/Inspiratory Valve Leaks/ObstructionsSoda Lime FailureMask/Tube LeakVaporizer Failure

Ventilator Pressure LossOxygen Port/Tank Pressure LossEndotracheal IntubationEsophageal Intubation

Oxygen Bottle ExhaustedRelief Valve Active

Note: More to come

45

Provided Data Examples

Systems System Vital Examples(Hundreds Total)

Compartment Examples(Thousands Total)

Assessments(Exhaustive)

Cardiovascular Heart RateCardiac OutputMean Arterial PressureBlood Volume

Pulmonary FlowBrain PressureHeart VolumesSubstance Concentrations

Complete Blood CountComprehensive Metabolic Panel

Blood Chemistry Blood pHOxygen SaturationShunt FractionHemoglobin Content

Respiratory Respiration RateTidal VolumeTotal Lung VolumePulmonary Resistance

Lung VolumesLung PressuresAir FlowSubstance Volume Fractions

Pulmonary Function Test

Energy Respiratory QuotientTotal Metabolic Rate

Skin TempHeat Transfer Rate

Environment Ambient TemperatureClothing Resistance

Renal Glomerular Filtration RateUrine Specific Gravity

Renal Blood FlowBladder Substance Concentrations

Urinalysis

GI Digestion Rate Stomach Contents

Drugs & Substances Partition CoefficientsAnesthesia Level

Plasma ConcentrationTissue Concentration

Anesthesia Machine Oxygen Bottle VolumeVentilator Pressure

Vaporizer substance fractionsTube flows

Note: These are only example outputs – there are many, many more

46

Other Included BioGears ToolsUnit Converter

Unit/Feature Testing

• Validate individual tools

• Verify individual feedback

• Alerts user to introduced bugsVerification Testing

• Full scenario suite to test all patient files, patient actions, substance effects, and equipment performance

• Each scenario indicates the physiologic outputs for comparison and generates error plots

Validation Testing

• Spreadsheet with referenced baselines

• Color coded error tables automatically generated for all System and relevant compartment data

Developer GUI

VentilatorPressureLossScenarioResultsReport 1 1 21.258999824523926

YpieceDisconnectScenarioResultsReport 1 1 23.98900008201599

AirwayInsultObstructionResultsReport 0 1 14.930999994277954

AtropineScenarioResultsReport 0 1 13.121000051498413

BasicScenario1ResultsReport 0 1 18.195000171661377

Verification Results Example

Developer GUI

47

• Virtual Heroes developed ‘Combat Medic’, for RDECOM STTC

• Uses BioGears for live physiology and after action data

• Intended to train Combat Medics on the top three preventable causes of death on the battlefield: Hemorrhage, Airway Obstruction and Tension Pneumothorax

• The prototype was tested at Fort Bliss, TX by Army combat medics

Combat Medic using BioGears

Images courtesy of Combat Medic project funded by Army RDECOM-STTC

Hemorrhage Airway Obstruction Tension Pneumothorax

Link to Video

48

• Runs via the APIInternally Funded

Demo GUI

49

Documentation and Tutorials• The website includes detailed documentation for each physiology system

and software components (e.g., CDM, Toolkit, SDK, Source Code)• This includes text and tables that explain: system background, model

limitations, equations used, and validation data sources and matrices • https://www.biogearsengine.com

Expand

50

Envisioned User Groups

Adds or replaces systems to extend the functionality

Ex. Physiology Modelers

BioGears Contributor

Use the engine as is via the API

Ex. Game Developers

Engine Integrator

Uses/extends CDM

Runs BioGears engine and/or other engine(s)

Ex. Mannequin Builder

External Model/ Engine Developer

Creates custom input to BioGears engine for research or instruction

Ex. Teaching Assistant

Researcher/ Educator

• The physiology engine has been designed and implemented with 4 user groups in mind.

• Engine functionality, fidelity and extensibility critical design decisions made to make BioGears user friendly

• Scope:• Providing an API with open source libraries

• BioGears is not a ‘game’ – it will power immersive training content and other M&S tools

51

• Worked with subcontractor UNC Eshelman School of Pharmacy• Pharmacodynamics also validated through scenario validation• All drugs validated in this manor

PK/Clearance Validation Examples

Bolus

InfusionBolus

Bolus

52

Using BioGears

• Canned or Dynamic Scenarios• Training and Simulation Scenarios• Physiology and Modeling Classroom

Education• Data Analysis• Physiologic Response Scenarios

Use-Case Options

• Integration of New Models, Systems, Actions, Conditions, and Events

• New Patients, Substances, and Drugs• New Initialization Parameters (blood

tests, lab results)• Validation and Verification• Data Analysis• Injury Assessment Scoring Input

Development Future

1. Needs and Requirements Assessment2. Validation and Calibration Data Determination3. Model Design and Implementation4. Model Verification – Unit Tests to Verify Functionality5. Model Calibration – Tuning Parameters to Meet Initial Data6. Model Validation – Use of Model/Feature in Combination To Validate

Functionality

Model/Feature Development Steps

53

Implementation

Setup/Modify

Next Values

Modified Nodal

Analysis

Calculate

Fluxes

Valves

Pass?

Set Node

QuantitiesAdvance Time

Modify Valve

States

Yes

No

Calculate

Quantities

Preprocess:

1. Systems use “Current” values to setup/modify “Next”

values via feedback mechanisms (outside of the solver)

Process:

2. Perform numerical integration by using linearization

(first order approximations) through Modified Nodal

Analysis (Ax=b)

a. Use KCL (total Flux at each node = 0) to

Calculate the Jacobian matrix (A) and right-

hand side vector (b) for each Node Potential

and Potential Source Flux (x)

b. Use the Eigen templated library linear solver

(FullPivLU) to solve for x vector

3. Calculate unknown Fluxes – using Trapezoid Rule

where applicable

4. Calculate Valves using assumed diode states (cannot

be solved directly) – iterate as necessary

5. Calculate and increment Compliance Path Quantities

– No other elements have dynamic Quantities (rigid

pipes)

6. Set Node Quantities (based on Path Quantities)

• Note: Transporter is called here

Postprocess:

7. Advance time by moving “Next” to “Current” values

Process

Preprocess

Postprocess

1

2

3

5

67

4

54

• Provides a medium for substance transport through the

human body

• Feedback related to insults/interventions propagated

through entire body

BioGears System Example: Cardiovascular Interaction

Cardiovascular

Renal

TissueGastrointestinal

Respiratory

Alveolar

Transfer

Digestion

Clearance

Tissue Diffusion

55

Example Scenario: Combat Multitrauma Showcase +

Environment ChangeHemorrhage & Tension Pneumothorax

Needle Decompression

Hemorrhage Reduced (Manual Pressure)

Tourniquet (Hemorrhage Stopped) & IV (Saline)

Morphine

High Altitude Environment (End of Current Validated Scenario)

12 min 60 min

Note: Does not include sympathetic nervous system – we are currently designing

56

PHARMACOKINETIC AND

PHARMACODYNAMIC MODELING

57

Pharmacokinetic Diffusion

• Substances are either perfusion-limited or permeability-limited during diffusion. All current drugs in the BioGears engine are perfusion-limited.

Perfusion Limited Diffusion

𝑉𝑇 ∗ ∆𝐶𝑇 = 𝑄𝑇 ∗ 𝐶𝑉 −𝑄𝑇 ∗ 𝐶𝑇𝐾𝑃

∆𝑀𝑇 = 𝑄𝑇 ∗ 𝐶𝑉 −𝑄𝑇 ∗ 𝐶𝑇𝐾𝑃

Ref. Khalil and Laer, 2011

𝑄𝑇 , 𝐶𝑉 𝑉𝑇 , 𝐶𝑇 , 𝐾𝑃 𝑄𝑇 , 𝐶𝑉𝑒𝑛

∆𝑀𝑇: 𝐶ℎ𝑎𝑛𝑔𝑒 𝑖𝑛 𝑚𝑎𝑠𝑠 𝑜𝑓 𝑠𝑢𝑏𝑠𝑡𝑎𝑛𝑐𝑒

𝑉𝑇: 𝑉𝑜𝑙𝑢𝑚𝑒 𝑜𝑓 𝑡ℎ𝑒 𝑡𝑖𝑠𝑠𝑢𝑒

𝑄𝑇: 𝑉𝑎𝑠𝑐𝑢𝑙𝑎𝑟 𝐵𝑙𝑜𝑜𝑑 𝐹𝑙𝑜𝑤

𝐶𝑇: 𝑆𝑢𝑏𝑠𝑡𝑎𝑛𝑐𝑒 𝑐𝑜𝑛𝑐𝑒𝑛𝑡𝑟𝑎𝑡𝑖𝑜𝑛 𝑖𝑛 𝑡ℎ𝑒 𝑡𝑖𝑠𝑠𝑢𝑒

𝐶𝑉: 𝑆𝑢𝑏𝑠𝑡𝑎𝑛𝑐𝑒 𝐶𝑜𝑛𝑐𝑒𝑛𝑡𝑟𝑎𝑡𝑖𝑜𝑛 𝑖𝑛 𝑣𝑎𝑠𝑐𝑢𝑙𝑎𝑟𝑡𝑢𝑟𝑒

𝐾𝑃: 𝑃𝑙𝑎𝑠𝑚𝑎: 𝑇𝑖𝑠𝑠𝑢𝑒 𝑝𝑎𝑟𝑡𝑖𝑡𝑖𝑜𝑛 𝑐𝑜𝑒𝑓𝑓𝑖𝑐𝑖𝑒𝑛𝑡

58

Pharmacokinetics – Partition Coefficients• An example of the PK properties from the substance files

are shown below.

• Partition coefficients can be directly input into the substance file, bypassing the engine calculation.

59

Pharmacokinetics - Clearance

𝑉𝑇 Volume mL

𝐶𝑇 Concentration ug/mL

𝑄𝑇 Flow mL/s

𝐾𝑃 Partition Coefficient

𝑑𝑇 Time Step s

∆𝑀𝑇 Mass Increment ug

𝐶𝑙𝑅 Renal Clearance mL/s/kg

𝐵𝑊 Body Weight kg

𝑓𝑢 Fraction Unbound

𝐶𝑙𝐼 Intrinsic Clearance mL/s/kg

𝐶𝑙𝐻 Hepatic Clearance mL/s/kg

𝐶𝑙𝑆 Systemic Clearance mL/s/kg

𝑉𝐶𝑅 Blood Volume Cleared Renal mL

𝑉𝐶𝐿 Blood Volume Cleared Liver mL

𝑉𝐶𝑆 Blood Volume Cleared Systemic mL

• Renal Clearance

• 𝑉𝐶𝑅 = 𝐶𝑙𝑅 ∗ 𝐵𝑊 ∗ 𝑑𝑇/2

• ∆𝑀𝑇 = 𝑉𝐶𝑅 ∗ 𝐶𝑇

• Hepatic Clearance

• 𝐶𝑙𝐻 =𝑄𝐿∗𝑓𝑢∗𝐶𝑙𝐼∗𝐵𝑊

𝑄𝐿+𝑓𝑢∗𝐶𝑙𝐼∗𝐵𝑊

• 𝑉𝐶𝐿 = 𝐶𝑙𝐻 ∗ 𝐵𝑊 ∗ 𝑑𝑇

• ∆𝑀𝑇 = 𝑉𝐶𝐻 ∗ 𝐶𝑇

• Systemic Clearance

• 𝑉𝐶𝑆 = (𝐶𝑙𝑆∗ 𝐵𝑊 ∗ 𝑑𝑇) − 𝑉𝐶𝑅 − 𝑉𝐶𝐿• ∆𝑀𝑇 = 𝑉𝐶𝑆 ∗ 𝐶𝑇

60

Pharmacodynamics

∆𝐸 =𝐸𝑚𝑎𝑥 ∗ 𝐶𝑝𝐸𝐶50 + 𝐶𝑝

𝐸𝐶50 = 𝐶𝑚𝑎𝑥32

• Drug effects are calculated based on the plasma concentration, the drug effect, and the concentration at 50% effect.

• The EC50 value was not readily available for the majority of drugs in question, so the EC50 value was calculated from the max concentration.

• The Cmax is shown circled on the

example plot.

61

• The following clinical effects were calculated:

• Heart Rate

• Diastolic and Systolic Pressure

• Respiratory Rate

• Tidal Volume

• Bronchodilation Level

• Sedation Level

• Neuromuscular Block Level

Pharmacodynamics

62

Agent Threat Example Scenario• Cortexiphan is a fictitious threat agent administered through the air.

• The substance parameters were modified in the agent file and a

scenario was created changing the ambient air to be 9.5%

cortexiphan.

Time(s)

Co

rte

xip

ha

n-P

lasm

aC

on

ce

ntr

ati

on

(ug

/mL

)

50 75 100 125 150 175 200 225 250 275 3000

50

100

150

200

250

300

350

400

450

Plasma concentration increases

with increased exposure time.

Time(s)

Resp

irati

on

Rate

(1/m

in)

0 30 60 90 120 150 180 210 240 270 30014

16

18

20

22

24

26

28

Respiration rate increases as

calculated by PK/PD response

model.

63

API

64

• Common Data Model • Overview

• Class Introduction

• Physiology Engine Interface• Static vs. Dynamic Engine Execution

• Inputs

• Conditions

• Actions

• Outputs

• Systems

• Compartments

• Assessments

• We will not go over the entire code base, just the forward facing classes available for application developers

Application Programming Interface Overview

65

• Property – Scalar, Functions, Enums, etc.

• Scalar is a double with a unit, with embedded unit converter

• System

• Physiology – Cardiovascular, Respiratory, Drugs, etc.

• Equipment

• Anesthesia Machine – Generic Machine

• ECG – Generic Waveform reader

• Inhaler – Optional spacer

• Environment – Properties external patient

• Environmental Conditions – Meteorology, Heat/Cool, ChemBio, etc.

• Patient – Body characteristics, Baselines, State

• Compartment – Specific anatomical and machine dynamics

• Flow, Volume, Pressure,

• Substance Mass/Concentration or Volume/Volume Fraction

CDM Classes (SE prefix)

66

• Substance – Anything being circulated in the blood or pulmonary systems, including drugs

• Configuration – Engine specific data that does not fit anywhere else

• Time step, Stabilization, Coefficients, etc.

• Circuit – Generic circuit solving library

• Scenario – Engine execution instructions

• Utils

• Unit Converter – Versatile conversion engine

• General Math – Generic saturation, Kelman equation, etc.

• Logging – Logging classes built on log4cpp

• Data Tracking – Write data to file each time step as the engine runs

• Physiology Engine Interface

• Generic interface for physiology methodology based on CDM

CDM Classes (SE prefix)

67

• Static execution of the engine based on a scenario file• Specify a patient file

• Request data to be output in a column tab delimited txt file

• Conditions

• Actions

• Dynamic execution of the engine• Initialize Engine with a patient, any conditions, and an optional results

file

• Time Controls• GetTimeStep, GetTime, AdvanceTime

• Provide Actions

• GetCompartments()

• GetSystems

• GetAssessment()

• GetSubstances()

Static vs. Dynamic Physiology Engine Interface

68

• Set up the engine to start at a specific statebool InitializeEngine(const SEPatient& patient, conststd::vector<const SECondition*>* conditions=nullptr)

• Patient• Anemia, Bradycardia, COPD, Pulmonary Shunt, Renal Stenosis,

Tachycardia, Heart Failure, Meal, Lobar Pneumonia, Pericardial Effusion

• Environmental• Initial Environment Conditions

• We have tested each condition individually, but you do have the option to stack conditions, we have not testing all combinations• Test that the engine can converge on stacked conditions

Conditions (Input)

69

• Instruct the engine to change its state in some way

void AdvanceModelTime()// Single Time Step

void AdvanceModelTime(double time, conststd::shared_ptr<CCompoundUnit>& unit)

bool ProcessAction(const SEAction& action)

• Action Types

• Patient – Various Insults and Interventions

• Environment – Configuration and Application

• Anesthesia Machine – Configuration and Insults

• Inhaler - Configuration

Actions (Input)

70

• Physiological state data

• Respiratory Rate, Heart Rate, Metabolic Rate, etc.

• Equipment and Environment state data

• Oxygen Tank Volume, Nozzle Loss, Heater Power, etc.

• Engine implementation does not have to provide every

output, although BioGears does

const SEEnvironment* GetEnvironment()

const SEBloodChemistrySystem* GetBloodChemistrySystem() … (much more physiology) …

const SEAnesthesiaMachine* GetAnesthesiaMachine()

const SEElectroCardioGram* GetElectroCardioGram()

Systems (Output)

71

• Compartments are a generic interface for the fluid dynamics data of the body, such as

Volumes, Pressures, In Flows, and Out Flows

• A compartment can represent various fidelities of data

• Skin, Right Arm, Liver, Left Heart

• Anesthesia Machine Ventilator, Mask, etc.

• Multiple compartment types to represent different fluid dynamic types

• Gas (Pulmonary), Liquid (Blood, Chyme, Urine), Thermal (Body Heat), Tissue (Extravascular)

• Compartments have a parent/child hierarchy

• There can be multiple compartments associated with anatomy

• Substance quantities for each substance is also provided in the compartment

• A vascular compartment includes the substance masses and concentration

• A pulmonary compartment will contain the volumes and volume fractions of all substances in that

compartment

const SEAnatomyCompartments* GetAnatomyCompartments()

const SEInhalerCompartments* GetInhalerCompartments()

const SEAnesthesiaMachineCompartments* GetAnesthesiaMachineCompartments()

Compartments (Output)

72

• Assessments are physiology data formed into various medical tests and panels intended for clinicians

• Some calculation may apply

• Complete Blood Panel, Complete Metabolic Panel, Pulmonary Function Test, and Urnialysis

• Provide an assessment object to the Engine for it to fill outSEPulmonaryFunctionTest pft(bg->GetLogger());

bg->GetPatientAssessment(pft);

• Various states on the patient or equipment can change during execution and state flags can be polled for these changes

• Antidiuresis, Asystole, CardiacArrest, …, RespiratoryAlkalosis, RightMainStemIntubation, Tachycardia, Tachypnea

• OxygenBottleExhausted, RefliefValveActive, etc.GetPatient().IsEventActive(CDM::enumPatientEvent::CardiacArrest)

Patient Assessments and Events (Output)

73

• Event Callbacks

• Along with polling for events, you can provide a callback object that

the engine will call when any event is triggered

• Exceptions

• Any time an engine gets out of its designed boundary conditions, it

will throw an exception of or derived from

CommonDataModelException

• Data Track

• You can have the engine write out any system or compartment

scalar into tab delimited file at each time step.

Callbacks, Error handling and Data Tracks

74

• Each engine can have its own log and will log the following types of data

• The Logger has the option to be given a LoggerForward class that an end user provides. The logger will call methods on this class whenever it logs giving the application a way to programmatically react to the engine

Logs

Type Description

Debug Detailed information about engine execution

Info General information of what the engine is doing

Warning The engine received something or is doing something that may or may not invalidate results

Error The engine has performed a calculation it was not designed for but will keep running, results are most likely invalid

Fatal The engine has entered a state it was not designed for and will stop execution immediately. BioGears will follow this by throwing an exception

75

• Each engine can have its own log and will log the following types of data

• Debug – Detailed information about engine execution

• Info– General information of what the engine is doing

• Warning – The engine received something or is doing something that may or may not invalidate results

• Error– The engine has performed a calculation it was not designed for but will keep running, results are most likely invalid

• Fatal– The engine has entered a state it was not designed for and will stop execution immediately. BioGears will follow this by throwing an exception.

• The Logger has the option to be given a LoggerForward class that an end user provides. The logger will call methods on this class whenever it logs giving the application a way to programmatically react to the engine

Logs

76

• The engine executes out of a bin directory, this is a break down of the directories and its files required for BioGears• config – Stabilization parameters, you may need to tweak these files if

you combine conditions

• ecg – The waveform set to use for the ecg

• environments* – a set of canned environments for the engine that the environment can initialize to

• nutrition* – a set of canned nutrition files that can be used with the ConsumeMeal condition and ConsumeNutrition action

• patients – a set of tested and validated patient files

• substances – the set of substance files for BioGears

• UCEDefs.txt – Unit conversion configuration file

• BioGearsConfiguration.xml – Override any BioGears configuration property. By default this file is empty.

*Not required by the engine

OnDisk Breakdown