Goals for Technical Architecture

Download Report

Transcript Goals for Technical Architecture

Digital Human –
Proposed Framework
Gerry Higgins
Tim Poston
Henry Kelly
Federation of
American Scientists
Cornerstone Elements of the Digital Human
Tools
Segmentation
Modeling
Animation
3D
4D (Motion, change)
Locomotion
Growth
Simulation
…
Pathology of Disease,
Syndromes
Clinical Patterns
Signs & Symptoms
Pathophysiology
VHP DATA SETS
Natural Biological
Variation
Aging
Biological Structure
Continuum
Physical Scales
Embryology
Gross Anatomy
Microscopic Anatomy
Submicroscopic Anatomy
Physiology
Biochemistry
INTEGRATED DIGITAL HUMAN
Structural Change
Scale & Resolution
ANCILLARY DATA SETS
MRI, CT, PET
Conventional Radiology
Conventional Anatomical
materials
Essential Tasks
I.
A technical architecture for organ model
sharing and simulation development in
biomedicine.
II.
A collaborative, open source
environment for model design,
communication, development and
validation.
Modeling of Biological Systems is Difficult
• Many physical scales may be active and important.
• Dynamic interaction — continuous motion and change
in components (mechanical, electrical, chemical).
• Highly non-linear, large deformations, history
modifies response.
• Massively parallel systems with hierarchical
signaling/control (neural and endocrine).
• Few rigid, static surfaces; freely changing interfaces.
• Enormous diversity between individuals
• All biological objects evolved from others and
inherit/conserve many characteristics.
• Vast amount remains unknown — even fundamentals.
New information about components, continually.
Biomedical simulation
• Great progress already for many body systems.
• Multiple processes (enzyme kinetics, heart action,
circulatory physiology, gait, growth, …).
• Multiple timescales (10-12sec molecule events, 103sec force display, 10-1sec graphics, sec… decade
prognosis).
• Multiple methods (finite element, compartment
models, multi-body mechanics, mesh-less particle
flow, Markov chain, neural net, …)
• Disjoint funding, communication via journal/ talk/
website/ etc.
• Model interaction for different scales or organs, rare.
• Interaction of real events at different scales or
organs can be critical for the human involved.
I. Goals for Technical Architecture
• As many groups as possible to share software
components.
• All models and simulations reviewed by the biomedical
research community and tested against empirical data.
• Trace data and procedures easily to primary source
(‘provenance’).
• Encourage creative, competing solutions.
• Compatibility with existing models.
• Eliminate artifacts of specific programming languages
and standards (base the logic in biology not
programming).
• Minimize overhead cost from heavyweight standards.
• Scalable, easily suppressing complexity or detail not
relevant to the user.
• Continuously adaptable to reflect new discoveries .
Ontology
Software ontology must be rooted in biology not
in an artifice of the programming
• Structure rooted in a small number of biological
primitives:
– Anatomy ontology based on Rosse (1998)
– Modules based on geometries, properties and
dynamics
– Cell ontology from BioSPICE
• Examples:
– Shape progenitor (e.g., a basic tube model applying
to veins, arteries, nerves, ducts, intestines, pores)
– Membrane progenitor (e.g., lipid layer around a
cell, skin around an animal)
Parent Modules
Characteristic
Examples
Geometry
Position, shape, orientation, connections, etc
Material properties
Elasticity, color, temperature, etc
Information transfer
Receptors, sensorimotor systems, etc
Dynamics
Shape change
Locomotion, contraction, pulsation, growth,
conformational change, etc.
Fluid flow
Hemodynamics, diffusion, etc.
Electrochemical
Excitation-contraction coupling, action
potential, resting potential, etc.
Biochemistry
Phosphorylation, enzyme kinetics,
intracellular signaling pathways, etc.
Engineering Standards (e.g., STEP)
Strengths:
• Proven methods for building consensus from diverse
development community (and much legacy code). Allows
collaboration among diverse teams
• Extensive operational experience in geometry (interoperation
of commercial CAD formats). Accelerating work in fluid,
electrical and other components.
• Operational version control/validation methods.
• Clear applicability for engineered devices (artificial heart,
catheters)
Weaknesses for biological modeling:
• Not designed for large changes in shape, changes in material
properties.
• May not extend easily to non-linear models, non-Newtonian
fluids, and other domains common in biological modeling.
Simulation-linking Standards
Strengths for biological modeling:
• Communication language standard — shape, force,
concentration, … — easier to agree than model internals.
• Existing models add ‘Wrappers’, don’t rebuild core code.
• Research continues on validity, range, speed of models.
• ‘Breadboarding’ joining of models does not freeze their
development.
Weaknesses for biological modeling:
• Costs in data transformation and transfer between models.
• Hard to tune for real-time interaction (e.g., 1-millisecond
haptic response).
What is a Wrapper?
• The module by which a model ‘speaks’ and ‘understands’ the
common exchange language.
• Interaction between models independent of the internal
operation.
• Model components may have their own wrappers: re-use
saves both development and wrapper-building time.
• Public functions accept/produce agreed biophysical
parameters.
• Interaction events pass shape description, forces,
biochemicals, fluid flow, pressure, and electrical activity.
• Interaction rules tested for software/biological validity.
• Specify level of detail required by application.
• Communication via a shared run-time module that registers
models, timestamps messages, maintains global sim-clock,
etc.
II. Building a Community
Goals:
• Widest possible collaboration and
sharing/reuse of components.
• Efficient management of review, bug
reports, software/biological validation.
• Clear identification of authors, sources of
data and methods.
• Ease in building business around extensions
and services.
Open Source Issues
• How will the community be organized?
• How is the technical infrastructure managed?
(Change control, bug reporting, peer review.)
• The collaborative process to coordinate work.
• Structure of licenses and legal agreements.
• Who will fund the project?
Examples of Coordination Groups and Teams
Examples of Teams
Project Leads
Oversight Committee
Agencies (NIH, DARPA, NSF)
Architecture Committee
?
Run-time communication
?
Heart
?
Vascular
?
Cell
?
Neuro
?
Immunology
?
Visualization
?
Whole Body Integration
?
Shape, force, etc. language
?
Databases
?
User Interface
?
Clinical Applications
?
Haptics
?
Diagnostic Imaging
?
Elements of a Strategy
• Build a community to oversee
development of open-architecture.
• Define ontologies and communication
/interface standards for key
components.
• Define interfaces allowing construction
of wrappers for existing code.
• Build exemplar kernel and key
components for each ontology.
• Who takes the lead?