Pith. sign in

REVIEW 3 major objections 4 minor 21 references

Holistic Specification of the Human Digital Twin: Stakeholders, Users, Functionalities, and Applications

T0 review · 3 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper argues that every human digital twin can be classified by six cumulative functionality levels and that a generic requirement list gives a reusable implementation guideline.

desk verdict Useful HDT requirements checklist undermined by self-confirming validation and one internal mapping contradiction. read the letter →

arxiv 2507.14859 v1 pith:K4HN7UZM submitted 2025-07-20 cs.HC cs.SYeess.SY

Nils Mandischer , Alexander Atanasyan , Ulrich Dahmen , Michael Schluse , Jürgen Rossmann , Lars Mikelsons This is my paper
classification cs.HCcs.SYeess.SY
keywords humandigitaltwinspecificationfunctionalitylevelsstakeholderanalysisrequirementsengineeringIndustry5.0human-systeminteraction
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims that the scattered field of human digital twins — digital models of a person that mirror physical, biological, psychological, or behavioral data — can be unified by a single specification with three parts: a small set of functionality levels, a map of stakeholders and users, and a generic requirements list. The authors propose six ordered levels — store, analyze, personalize, predict, control, optimize — in which each higher level includes the lower ones, with communication treated as an orthogonal capability. Starting from a thought experiment in which a person carries their HDT as a protected parameter set on a key card, they brainstorm applications for each user group, detail three representative applications, and derive requirements covering safety, reliability, law, structure, connectivity, and accessibility. If the specification holds, HDT implementations can be planned for reuse across domains instead of being rebuilt for each application.

What carries the argument

The load-bearing object is the six-level functionality scale: store, analyze, personalize, predict, control, and optimize. Levels are cumulative, so a higher level presupposes all lower ones, and 'communicate' is deliberately kept orthogonal because every level needs it. The scale is generated by a sentence-completion creativity technique applied to each user group, and the resulting application table doubles as the paper's evidence that the scale covers the space of HDT uses. A second machinery is the derived requirements table, organized into six categories, which turns the stakeholder and user analysis into a reusable implementation checklist.

What would settle it

Ask independent HDT practitioners to classify a set of deployed or proposed HDT systems into the six levels, including at least one system that predicts a user's future state without first personalizing any configuration; if such a system cannot be placed on the scale without contradiction, the claim that higher levels include all lower ones is refuted.

Watch

Extended reading notes

Core claim

The central claim is that what makes a human digital twin is best captured by what it is used for, and that all uses fall into six cumulative levels of functionality: store, analyze, personalize, predict, control, and optimize. The paper derives this scale by completing the sentence 'The USER uses the HDT to FUNCTIONALITY APPLICATION' for each identified user group, then groups the resulting applications into the six levels, producing an appendix table that it presents as validation of the scale. Three selected applications — individualized medication, smart-home control, and factory productivity optimization — are profiled in detail to show that the levels correspond to real and escalating demands for models, data, interfaces, and regulatory compliance. The same holistic analysis yields a generic requirements table intended as a guideline for implementing reusable HDTs.

Load-bearing premise

The specification assumes that the six functionality levels are the right and complete abstraction for every human digital twin use, and that the authors' own brainstormed application table is enough to show it.

Editorial extensions

If this is right

  • Developers can decide which functionality level an application targets and reuse models and data from the lower levels instead of starting from scratch.
  • Researchers and industrial use-case owners can position their HDT prototypes on the same scale, making cross-domain comparison and generalization visible.
  • The generic requirements table provides a pre-implementation checklist covering safety, digital sovereignty, legal conformity, modularity, interoperability, and accessibility.
  • Existing systems such as the electronic patient record can be understood as level-0 HDTs that gain higher-level functionality when composed with additional models.
  • The three detailed application profiles indicate that moving up the levels increases the number of models, interfaces, and legal constraints that an implementation must handle.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The six-level scale could be used as a maturity model: an HDT implementation is only as advanced as the highest level it reliably supports, which would let buyers and regulators compare systems with a single metric.
  • The singleton requirement 'one person, one HDT' implies a portable identity and data-portability standard; the key-card mechanism in the thought experiment is one way to realize it, but the requirement itself pushes toward interoperable HDT-to-HDT protocols.
  • The paper's observation of growing complexity across levels suggests a cost model in which higher-level applications are disproportionately expensive; that claim could be tested by counting models, interfaces, and compliance requirements per application in a larger sample.
  • The requirements list could be turned into a certification checklist by operationalizing each requirement as a test, for example verifying that an HDT can purge all data by a scheduled date for 'plannable death.'
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper proposes a conceptual specification for a holistic human digital twin (HDT). It identifies stakeholders and user groups, introduces six ordered functionality levels (store, analyze, personalize, predict, control, optimize), and compiles a table of applications for each user group and functionality level. Three applications are elaborated in profiles, and a list of generic requirements is derived. The authors intend the specification to serve as a guideline for implementing reusable, holistic HDTs across domains such as healthcare, smart homes, and factory productivity.

Significance. If the framework were soundly validated, this paper would provide a shared vocabulary and requirements baseline for the growing HDT community, and the functionality-level abstraction could help compare and compose HDT applications. The paper is clearly written, honest about its basis in a thought experiment, and usefully connects to standards (ISO/IEC 30173, GDPR) and prior HDT work. However, the evidence for the validity and completeness of the abstraction is currently insufficient: the classification of applications onto levels is internally inconsistent (see Major Comment 1) and circular (Major Comment 2). These issues undermine the central claim that the six levels are a validated abstraction. With substantial rework, the framework could become a useful contribution; as it stands, the specification is not yet reliable.

major comments (3)
  1. [Section III-E, Table III vs. Section IV-A/IV-B, Table I] Table III assigns 'smart home: room/device adjustment; environment control' to Personalize (Level II) in the 'Me' row, but Section IV-B classifies Smart Home as Level IV (Control), and Table I labels it 'Level IV: Smart Home'. Likewise, Table III lists 'personalized therapy; medication' under Personalize (Level II) for the Psychologist column, while Section IV-A explicitly classifies the medication decision-support system as Level III (Predict) because there is no immediate feedback loop, and Table I labels it 'Level III'. Section IV-B even acknowledges that the scenario title suggests Level II while the device control corresponds to Level IV, yet Table III is not corrected. Since the claim in Section III-E that sufficiently diverse applications per level 'validate the model' rests on Table III, these contradictions mean the levels lack operational definitions and the validation is not reproducible. These are not edge cases; they are two of the three applications selected for detailed validation.
  2. [Section III-D and III-E] The functionality levels are derived from the authors' brainstorming of applications, and the applications in Section III-E are then generated to populate those same levels; the existence of such applications is used to 'validate' the model in Section III-E. This is a self-confirming procedure: any arbitrary level set could be populated by brainstorming fitting examples, so the evidence does not support the claim that the six levels constitute a valid or complete abstraction. To make the validation meaningful, the authors should provide a priori operational definitions with decision rules for assigning an application to a level, or use independent raters, or derive a falsifiable prediction (for example, that model count, interface complexity, or required latency increases monotonically with level). Without such a test, the central claim is unsubstantiated.
  3. [Sections III-A, III-C, and VI] The derivation is explicitly based on a single structured brainstorming session with four experts (Section III-A), and the authors state that the user list 'can be extended at will' (Section III-C) and that applications are only exemplary. Nevertheless, the title and conclusion claim a 'holistic specification' and a 'comprehensive list of requirements' (Section VI). A vision paper may legitimately propose a framework rather than prove its completeness, but the burden is to justify that a four-expert session can yield comprehensive coverage. Without a systematic stakeholder-analysis method, a literature corpus analysis, or a saturation argument, the 'holistic' and 'comprehensive' terms overstate what is demonstrated. The authors should either temper these claims or provide a reproducible method for establishing completeness.
minor comments (4)
  1. [Section V, Table II] The text discusses 'Universal Design paradigm (F3)' and 'economic viability (F4)' as accessibility requirements, but Table II lists only F1 (Participation) and F2 (Human understandable I/O). Please add F3 and F4 to the table or remove the references; otherwise the table is not the 'comprehensive' list it claims to be.
  2. [Table II, item B2] The phrase 'save state' should read 'safe state'.
  3. [Table II, item D7] The word 'paramaterization' should be 'parameterization'.
  4. [Sections II and V] The terms 'Brown Field' and 'Green Field' should be lowercased and defined on first use; 'brownfield' is the standard spelling.

Circularity Check

1 steps flagged · score 6.0 of 10

The validation of the six functionality levels is self-referential: the levels are derived from the authors' brainstormed applications, then 'validated' by brainstorming applications into those same levels.

  1. self definitional [Section III-D (Six Levels of Functionality) and Section III-E (Applications); Table III]
    "For each user, some applications are derived and, consequently, grouped by similar uses. The usage categories were ordered by the amount of functionality required from the HDT. ... For all users and levels of functionality, we brainstorm potential applications ... This step is also used for validation of the levels of functionality. We are able to identify sufficiently diverse applications for each level of functionality and user group, validating the model."

    The six functionality levels are induced from the authors' brainstormed applications ('some applications are derived and, consequently, grouped'), and then the same brainstormed applications are generated against those levels ('for all users and levels of functionality, we brainstorm potential applications') and used as evidence that the levels are valid. A non-empty entry for each level is guaranteed by the generation step because the levels are used as the columns of the application table. The claimed validation therefore adds no information beyond the construction procedure: the framework and its supporting evidence come from the same self-authored brainstorming loop.

full rationale

The central derivation chain is: brainstorm applications, define six functionality levels from those applications, brainstorm another set of applications into the levels, cite the filled table as validation, and select three examples from that same table to 'validate the overall framework'. The last three steps cannot provide independent evidence because the evidence is produced by the same procedure that produced the framework. The paper even states the validation criterion as the ability to 'identify sufficiently diverse applications for each level of functionality and user group,' which is exactly the outcome the generation step was designed to produce. No external benchmark, independent dataset, or machine-checked derivation is supplied. The self-citation [5] (Perspectives-Observer-Transparency) is used only as an analogy and to combine models; it is not load-bearing for the six levels or the requirements. There are also internal consistency issues (e.g., 'personalized therapy; medication' is listed under Personalize in Table III while the detailed medication application is classified as Level III), but these concern correctness and robustness rather than circularity. The paper is transparent about its brainstorming methodology and the requirements list may still be useful as a checklist, so the circularity is partial rather than total.

Assumptions & free parameters 1 free parameters · 7 assumptions · 0 invented entities

The paper introduces no new physical or mathematical entities. Its constructs are conceptual: the six functionality levels, the requirement categories, and the notion of a holistic HDT. These are categorizations and guidelines, not claimed inventions in the sense of new particles or forces. The main load-bearing assumptions are the validity of the levels, the representativeness of the thought experiment, and the sufficiency of the brainstorming process.

free parameters (1)
  • number of functionality levels = 6
    Hand-chosen structural parameter of the framework, not derived from data or first principles. The number of levels could be different, and the paper does not justify why six is optimal.
assumptions (7)
  • ad hoc to paper The six levels of functionality (store, analyze, personalize, predict, control, optimize) form a valid and complete abstraction of HDT capabilities.
    Introduced in Section III-D as the paper's own framework, with no independent justification beyond analogy to knowledge development theory.
  • domain assumption The thought experiment of an idealized HDT ecosystem is a reasonable basis for deriving user needs and requirements.
    Section III-A describes the thought experiment. The entire analysis rests on this imagined scenario being representative of future real-world HDT usage.
  • domain assumption The brainstorming group of four technical experts from modeling, simulation, digital twins, and human-machine interaction is sufficient to comprehensively identify stakeholders, users, and applications.
    Section III states the group composition. No evidence is provided that this small, technically homogeneous group covers all relevant perspectives, such as clinical, legal, or end-user views.
  • ad hoc to paper The 'one person, one HDT' singleton principle is desirable and feasible.
    Requirement D4 in Table II asserts a single unique HDT per person, but the paper does not analyze the technical and social challenges of enforcing this across multiple providers and jurisdictions.
  • ad hoc to paper Zero obsolescence is a necessary requirement for HDT implementations.
    Section V-B introduces this requirement. The paper explicitly states it is 'more restrictive' than low obsolescence, but offers no feasibility analysis or argument that it is achievable.
  • domain assumption Existing digital twin standards such as ISO/IEC 30173:2023 are applicable to human digital twins.
    Section V-E cites the standard and assumes it extends naturally to HDTs, without discussing gaps or necessary extensions for human-specific data.
  • domain assumption The Perspectives-Observer-Transparency model from the authors' prior work [5] is a valid ontology for combining HDT models.
    Section III-D uses the model as the basis for the 'fractal' combination with functionality levels. Since the model is from the same authors and not independently verified, it is a self-referential assumption.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Holistic Specification of the Human Digital Twin: Stakeholders, Users, Functionalities, and Applications." pith.science (2026). https://pith.science/paper/K4HN7UZM

@misc{pith2026250714859,
  author       = {Pith},
  title        = {Pith review of: Holistic Specification of the Human Digital Twin: Stakeholders, Users, Functionalities, and Applications},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/K4HN7UZM}},
  note         = {Machine review of arXiv:2507.14859}
}
read the original abstract

The digital twin of humans is a relatively new concept. While many diverse definitions, architectures, and applications exist, a clear picture is missing on what, in fact, makes a human digital twin. Within this context, researchers and industrial use-case owners alike are unaware about the market potential of the - at the moment - rather theoretical construct. In this work, we draw a holistic vision of the human digital twin, and derive the specification of this holistic human digital twin in form of requirements, stakeholders, and users. For each group of users, we define exemplary applications that fall into the six levels of functionality: store, analyze, personalize, predict, control, and optimize. The functionality levels facilitate an abstraction of abilities of the human digital twin. From the manifold applications, we discuss three in detail to showcase the feasibility of the abstraction levels and the analysis of stakeholders and users. Based on the deep discussion, we derive a comprehensive list of requirements on the holistic human digital twin. These considerations shall be used as a guideline for research and industries for the implementation of human digital twins, particularly in context of reusability in multiple target applications.

Figures

Figures reproduced from arXiv: 2507.14859 by the authors.

Figure 1
Figure 1. Sketch of the brainstorming approach and examples of the workshop documentation. The workshop language was German. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Abstraction of usage/functionality categories. The “communicate” [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. There seems to be a fractal within the HDT and its models. This could lead to same methods being applicable to diverse scales of the HDT: for specification of functionalities and applications, and for selection and networking of models. E. Applications For all users (Section III-C) and levels of functionality (Section III-D), we brainstorm potential applications, in [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

21 extracted references · 21 canonical work pages

  1. [1]

    Preliminary systemic model of (human) digital twin,

    Y . Naudet, C. Stah, and M. Gallais, “Preliminary systemic model of (human) digital twin,” in PErvasive Technologies Related to Assistive Environments, 2023

    work page 2023

  2. [2]

    Experi- mentable digital twins—streamlining simulation-based systems engi- neering for industry 4.0,

    M. Schluse, M. Priggemeyer, L. Atorf, and J. Rossmann, “Experi- mentable digital twins—streamlining simulation-based systems engi- neering for industry 4.0,” IEEE Transactions on Industrial Informatics, vol. 14, 2018

    work page 2018

  3. [3]

    Human digital twin in the context of industry 5.0,

    B. Wang et al. , “Human digital twin in the context of industry 5.0,” Robotics and Computer-Integrated Manufacturing , vol. 85, 2024

    work page 2024

  4. [4]

    Human digital twin in industry 5.0: A holistic approach to worker safety and well-being through advanced ai and emotional analytics,

    S. Davila-Gonzalez and S. Martin, “Human digital twin in industry 5.0: A holistic approach to worker safety and well-being through advanced ai and emotional analytics,” Sensors, vol. 24, 2024

    work page 2024

  5. [5]

    Perspectives-observer-transparency – a novel paradigm for modelling the human in human-to-anything interaction based on a structured review of the human digital twin,

    N. Mandischer, A. Atanasyan, M. Schluse, J. Roßmann, and L. Mikel- sons, “Perspectives-observer-transparency – a novel paradigm for modelling the human in human-to-anything interaction based on a structured review of the human digital twin,” in IEEE International Conference on Systems, Man, and Cybernetics (SMC) , 2024

    work page 2024

  6. [6]

    Networking architecture and key supporting technologies for human digital twin in personalized healthcare: A comprehensive survey,

    J. Chen, C. Yi, S. D. Okegbile, J. Cai, and X. Shen, “Networking architecture and key supporting technologies for human digital twin in personalized healthcare: A comprehensive survey,” 2023

    work page 2023

  7. [7]

    Archi- tecture of a human-digital twin as common interface for operator 4.0 applications,

    A. L ¨ocklin, T. Jung, N. Zazdi, T. Ruppert, and M. Weyrich, “Archi- tecture of a human-digital twin as common interface for operator 4.0 applications,” Procedia CIRP, vol. 103, 2021

    work page 2021

  8. [8]

    Development and verification of a digital twin patient model to predict specific treatment response during the first 24 hours of sepsis,

    A. Lal et al., “Development and verification of a digital twin patient model to predict specific treatment response during the first 24 hours of sepsis,” Crit Care Explor., vol. 2, 2020

    work page 2020

Show all 21 references
  1. [9]

    Human digital twin-based interactive dashboards for informal caregivers of stroke patients,

    M. W. Lauer-Schmaltz, I. Kerim, J. P. Hansen, G ´abor M ´at´e Guly ´as, and H. B. Andersen, “Human digital twin-based interactive dashboards for informal caregivers of stroke patients,” in PErvasive Technologies Related to Assistive Environments , 2023

    2023

  2. [10]

    Montini et al

    E. Montini et al. , Trusted Artificial Intelligence in Manufacturing: A Review of the Emerging Wave of Ethical and Human Centric AI Technologies for Smart Production . now, 2021

    2021

  3. [11]

    Human digital twin for personalized healthcare: Vision, architecture and future directions,

    S. D. Okegbile, J. Cai, D. Niyato, and C. Yi, “Human digital twin for personalized healthcare: Vision, architecture and future directions,” IEEE Network, vol. 37, 2022

    2022

  4. [12]

    Towards democratization of digital twins: Design principles for trans- formation into a human-building interface,

    K. S. Lee, J.-J. Lee, C. Aucremanne, I. Shah, and A. Ghahramani, “Towards democratization of digital twins: Design principles for trans- formation into a human-building interface,” Building and Environment, vol. 244, 2023

    2023

  5. [13]

    A human digital twin of disabled workers for production planning,

    V . Mordaschew, S. Duckwitz, and S. Tackenberg, “A human digital twin of disabled workers for production planning,” in 5th International Conference on Industry 4.0 and Smart Manufacturing , 2024

    2024

  6. [14]

    Counteracting agile retro- spective problems with retrospective activities,

    C. Matthies, F. Dobrigkeit, and A. Ernst, “Counteracting agile retro- spective problems with retrospective activities,” in Systems, Software and Service Process Improvement , 2019

    2019

  7. [15]

    Personal health records: a scoping review,

    N. Archer, U. Fevrier-Thomas, C. Lokker, K. A. McKibbon, and S. E. Straus, “Personal health records: a scoping review,” Journal of the American Medical Informatics Association , vol. 18, no. 4, 07 2011

    2011

  8. [16]

    Die wissenstreppe,

    K. North, “Die wissenstreppe,” Wissensorientierte Un- ternehmensf¨uhrung, 2016

    2016

  9. [17]

    Duolingo. gamified learning through translation,

    P. Munday, “Duolingo. gamified learning through translation,” Journal of Spanish Language Teaching , vol. 4, 2017

    2017

  10. [18]

    Asimov, I, Robot

    I. Asimov, I, Robot. Gnome Press, 1950

    1950

  11. [19]

    Digital twin - concepts and terminology,

    ISO/IEC 30173:2023, “Digital twin - concepts and terminology,” 2023

    2023

  12. [20]

    Goldsmith, Universal Design

    S. Goldsmith, Universal Design. Taylor & Francis Group, 2000

    2000

  13. [21]

    Directive (EU) 2019/882 of the European Parliament and of the Council of 17 April 2019 on the accessibility requirements for products and services,

    “Directive (EU) 2019/882 of the European Parliament and of the Council of 17 April 2019 on the accessibility requirements for products and services,” Official Journal of the European Union, 2019. TABLE III APPLICATIONS OF THE HDT. Function Me inEveryday LifeWork PlannerShiftSu...

    2019

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.