Digital Human – Proposed Framework

1. Digital Human –Proposed Framework Gerry Higgins Tim Poston Henry Kelly Federation of American Scientists

2. 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 EXTENSIBLE PRODUCTS VHP DATA SETS Natural Biological Variation Aging Structural Change Scale & Resolution Biological Structure Continuum Physical Scales System Organ Tissue Cell Molecule Embryology Gross Anatomy Microscopic Anatomy Submicroscopic Anatomy Physiology Biochemistry ANCILLARY DATA SETS MRI, CT, PET Conventional Radiology Conventional Anatomical materials INTEGRATED DIGITAL HUMAN

3. 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.

4. 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.

5. 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, 10-3sec 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.

6. 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 .

7. 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)

8. Parent Modules

9. 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. Engineering Standards (e.g., STEP)

10. 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).

11. 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.

12. 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.

13. 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?

14. Examples of Coordination Groups and Teams

15. 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?