01 PERSONAL SITE
/
← RESEARCHER

Interscalar medicine / long-form research note / January 2025

The Interscalar Model as a Foundation for Medical Artificial Intelligence

Contents

  1. More data is not the same as more clinical knowledge
  2. What “interscalar” means
  3. The event as the smallest meaningful unit
  4. Why this architecture could help medical AI
  5. Explainability: a narrower and stronger claim
  6. Practical scenarios - Remote rehabilitation - Acute deterioration - Precision oncology - Medication safety
  7. Counterarguments and limits
  8. From concept to a testable system
  9. Conclusion
  10. References

More data is not the same as more clinical knowledge

Medical AI is often described as a problem of scale: more records, more images, more sensor measurements, and larger models should produce better decisions. Yet a clinical fact is rarely meaningful in isolation. A heart rate of 120 may describe exertion, fever, anxiety, arrhythmia, a faulty wearable, or a value entered hours after it was measured. The number is the same; the clinical meaning changes with time, source, purpose, method, and surrounding events.

This is why the central problem is not only how much data an AI system receives, but what relationships survive when the data are transformed into model inputs. Electronic records are created during care, billing, communication, and administration rather than under a controlled experimental protocol. Their missingness is not random: one study found that sicker patients tended to have more complete records, so “absence of data” can itself encode health status and patterns of contact with the health system [5]. A 2023 systematic review still found no standard approach to EHR data-quality assessment, despite recurring dimensions such as completeness, correctness, concordance, plausibility, currency, conformance, and bias [6]. A useful operational baseline is the harmonized framework of Kahn and colleagues: assess conformance, completeness, and plausibility, and state whether each check is an internal verification or a validation against an accepted external reference [32]. Quality is therefore not a single score; it is fitness for a specified use.

The interscalar model is proposed as a way to preserve these relationships. In this article, it means:

An event-centred architecture that links observations, actions, intentions, and outcomes across biological, temporal, personal, and organizational scales while retaining provenance, uncertainty, and the context in which each record is valid.

It is not itself an AI algorithm. It is a disciplined representation on which statistical, causal, symbolic, or machine-learning methods may operate.

What “interscalar” means

Medicine already has a well-developed tradition of multiscale modelling: connecting genes and proteins to cells, tissues, organs, and whole-body physiology. Noble’s work on cardiac modelling showed why organ function cannot be read directly from the genome [1], and later reviews described ways in which machine learning and mechanistic multiscale models can complement one another [2].

The proposed interscalar model is broader in a different direction. It connects not only biological levels, but four kinds of scale:

  1. Biological scale: molecule → cell → tissue → organ → person → population.
  2. Temporal scale: milliseconds of a waveform → daily behaviour → months of rehabilitation → years of chronic disease.
  3. Observational scale: device → patient or family report → clinician assessment → care team → institution.
  4. Decision scale: measurement → interpretation → intervention → response → revised goal.

A useful implementation would not merge all these layers into one undifferentiated feature vector. It would keep the links explicit and allow each clinical task to select a justified view of the record.

The event as the smallest meaningful unit

The original seven fields remain a useful minimum:

  • event;
  • source;
  • time;
  • performer;
  • goal;
  • outcome;
  • data quality.

For safe medical-AI work, that envelope should be expanded. A practical event record should answer:

  • What happened? Event type, value, unit, status, and clinically relevant subject or target.
  • When did it happen? Event time or interval, not only database-entry time; uncertainty should be retained when the time is approximate.
  • Who or what asserted it? Patient, relative, clinician, laboratory, device, or derived algorithm, with identity and version where appropriate.
  • Where and under what conditions? Home, ward, operating theatre, exercise session, fasting state, device position, protocol, and method.
  • Why was it recorded or performed? Screening, diagnosis, monitoring, therapy, administrative requirement, or a patient-defined goal.
  • What preceded and followed it? Inputs, intervention, expected state, observed outcome, and relevant competing events.
  • How reliable is it? Completeness, plausibility, calibration, measurement error, missingness reason, confidence, and whether the value was corrected.
  • Where did this representation come from? Original source, transformations, terminology mappings, dataset version, model version, and access policy.

In compact notation, an event can be represented as:

e = {subject, type, value, effective_time, recorded_time, source, actor, context, purpose, inputs, outcome, quality, uncertainty, provenance, policy}

Events then form a graph or ordered stream. Its links must distinguish different claims: occurred-before, part-of, derived-from, performed-by, pursues-goal, followed-by, and — only where supported by a causal design — caused. Temporal adjacency, provenance, and causation are not interchangeable.

This approach does not require a new exchange standard. HL7 FHIR already separates clinically relevant time from issuance time in Observation, identifies performers and encounters, and supports links to derived observations [18]. Its Provenance resource records the entities, activities, and agents involved in producing a resource and is aligned with the W3C PROV model [17, 19]. ISO 13940 supplies concepts for clinical processes and continuity of care [20]. The interscalar model is therefore most credible as a profiling and coordination layer over existing standards, not as a replacement for them.

Why this architecture could help medical AI

1. It can reduce false equivalence

Two equal values should not automatically become equal training examples. A patient-measured blood pressure after climbing stairs, a nurse-measured resting pressure, and a value copied from an older note have different evidential status. Context allows the system to stratify, exclude, or model those observations appropriately.

2. It makes provenance inspectable

When an output is challenged, the system should be able to reconstruct which source records, transformations, terminology mappings, and model version contributed to it. This is especially relevant for patient-generated data. Recent work has shown that provenance and context can be exchanged with EHRs using RDF and FHIR, although that prototype still requires practical evaluation with clinicians [4]. Provenance does not prove that a measurement is true; it shows where the claim came from and how it changed.

3. It supports task-specific context instead of record dumping

An oncologist, physiotherapist, pharmacist, and emergency physician need different views of the same longitudinal record. A context-based EHR prototype in neuro-oncology used ontologies and disease models to aggregate records and tailor relevant information, demonstrating the feasibility of this general direction while also emphasizing the need to study clinicians’ task-specific information needs [3].

4. It can expose dataset and workflow shift

If acquisition site, device version, staffing context, protocol, and time are represented, monitoring can ask not merely whether the input distribution changed, but where the change entered the care process. This does not prevent model drift, but it makes investigation and subgroup analysis more actionable.

The need is empirical, not hypothetical. A pneumonia model varied across hospital systems, and the hospital-system label alone strongly separated pneumonia prevalence in one combined dataset [33]. COVID-19 radiograph models were shown to rely on acquisition-related confounders rather than pathology and then fail at new hospitals [34]. In a 2026 prospective validation of an updated proprietary sepsis model across four US health systems, encounter-level AUROC ranged from 0.82 to 0.92, but positive predictive value remained 0.13–0.26 and the authors reported substantial institutional variability and alert burden [35]. A single pooled metric would hide much of this operational risk.

This produces a context paradox. Site, device, and workflow variables are valuable for stratification and surveillance, yet the same variables can become shortcuts if a predictor is free to exploit them. A safe event architecture should therefore classify contextual fields into three channels: (1) clinically justified inputs available to the model at decision time; (2) audit-only variables used for drift, fairness, and error analysis but withheld from prediction; and (3) prohibited variables that encode future information, direct labels, or unjustified proxies. The assignment is task-specific and must be documented, tested, and reviewed after deployment.

5. It can separate prediction from intervention

Prediction answers, “What is likely to happen?” Clinical action asks, “What would happen if we intervened?” Those are different questions. Causal and counterfactual methods require explicit assumptions about treatment assignment, confounding, time zero, and outcomes [9]. Target-trial emulation provides one disciplined way to formulate causal questions from observational data when a randomized trial is unavailable [10]. An interscalar event history may provide better inputs for such analyses, but it cannot manufacture causal identification from provenance alone.

Explainability: a narrower and stronger claim

The original text says that the model enables explainable decision support in which the algorithm shows both its conclusion and the reasons behind it. That claim is too broad without qualification.

The architecture can provide three useful forms of transparency:

  1. Data traceability: which events and source versions were used.
  2. Process traceability: which rules, transformations, model, threshold, and workflow produced the output.
  3. Clinical presentation: which patient facts, goals, uncertainties, and alternatives are relevant to the user’s decision.

None is automatically a faithful explanation of a black-box model’s internal computation, and none establishes causality. Ghassemi and colleagues argue that current explainability methods can create false reassurance and should not substitute for rigorous internal and external validation [7]. Rudin argues that in high-stakes settings, inherently interpretable models should be preferred when they can perform the task adequately [8]. The defensible claim is therefore that the interscalar model can make a decision more auditable and contextually intelligible, not that every model built on it becomes explainable.

Practical scenarios

Remote rehabilitation

A patient’s step count falls for five days. A conventional alert may classify this as functional deterioration. An interscalar record can connect the decline to a physiotherapist’s exercise plan, a pain flare reported by the patient, a device replacement, a family-care obligation, medication changes, and the next standardized mobility assessment.

The system might then present several testable interpretations: true loss of function, reduced adherence, altered measurement, or a temporary contextual constraint. It could ask for a missing pain score or repeatable walking test instead of immediately escalating. It still must not infer that any one event caused the decline without an appropriate study or clinical assessment.

Acute deterioration

An early-warning system sees rising respiratory rate, falling oxygen saturation, and a laboratory abnormality. Context can distinguish measurements taken before and after oxygen therapy, identify that one value came from a poorly perfused sensor, preserve the clinician’s response, and show whether an alert was acknowledged or overridden. The unit of evaluation becomes the human–AI workflow, not only the AUROC of a prediction model.

Precision oncology

A treatment decision may depend on a molecular variant, specimen quality, tumour site, prior therapy, organ function, performance status, patient preference, and local access to treatment. The interscalar representation can keep those levels connected and identify the evidence and version behind each statement. It cannot guarantee that a cross-scale association is biologically causal or that a recommended therapy improves outcomes.

Medication safety

A dosing recommendation can be linked to the current medication order, renal function at the relevant time, body weight and measurement method, recent dialysis, the prescriber, the applicable protocol, and the outcome after the change. This creates an auditable case record. It also creates a risk of automation bias: systematic reviews and simulated prescribing studies show that users may accept incorrect decision-support advice, so verification, interface design, training, and accountability remain essential [12].

Counterarguments and limits

“Existing standards already do this.” Partly true. FHIR, W3C PROV, ISO 13940, clinical terminologies, and common data models cover much of the required structure. The proposal has value only if it defines a coherent minimal profile, resolves cross-resource relationships, and demonstrates measurable benefit. Renaming existing fields is not innovation.

“More metadata means more burden.” Also true. Context can increase documentation time, storage, validation work, and integration cost. Automatically inferred context may be wrong; manually captured context may be incomplete. The model should require only metadata that changes an identified decision, risk control, or evaluation.

“Provenance creates trust.” Provenance supports authentication and reproducibility, but a precisely traced false measurement remains false. Source prestige is not ground truth, and a long audit trail can create the appearance of certainty.

“The model will remove bias.” It will not. Bias may enter through access to care, the choice of outcome, missing data, labels, workflow, or allocation decisions. A widely used population-health algorithm exhibited racial bias because healthcare cost was used as a proxy for health need [11]. Context may help reveal such proxy choices, but fairness must be tested with clinically relevant outcomes and subgroup analyses.

“A complete history will reveal causes.” It will not. Confounding, measurement error, selection bias, informative missingness, and temporal leakage remain. Adding variables can amplify bias or encode future information unavailable at the intended decision time.

“If context is useful, the predictor should receive all of it.” No. Hospital identity, scanner type, ordering pattern, clinician behaviour, and record density may be legitimate monitoring variables but dangerous predictive features. Withholding them does not automatically remove their proxies, so shortcut tests, cross-site validation, temporal validation, and ablation by context are still required [33, 34].

“A human in the loop guarantees safety.” It does not. Humans can over-rely on automation, ignore frequent alerts, or be unable to verify a system under time pressure. Responsibility, override logic, uncertainty communication, and the performance of the human–AI team must be evaluated prospectively.

Privacy risk increases with context. Fine-grained timelines, location, family relationships, rare events, and device metadata make re-identification easier. Access control, purpose limitation, minimization, retention rules, and privacy-preserving computation must be designed at the event and linkage levels. Patents describe technical approaches such as context-sensitive decision support, performance-ranked clinical rules, homomorphic processing, decision epochs derived from sensor-linked event histories, and Transformer prediction over longitudinal event tokens [29–31, 40, 41]. These are prior-art documents, not evidence of clinical validity, safety, regulatory acceptance, or freedom to operate.

From concept to a testable system

A credible development programme should proceed in stages:

  1. Define the intended use. Specify user, patient population, decision, setting, output, action, and foreseeable misuse. Do not begin with a universal patient graph.
  2. Specify a minimum event profile. Map it to FHIR resources and W3C PROV; use controlled terminologies and explicit versions. Separate event time, recorded time, and decision time.
  3. Write data contracts and quality rules. State required fields, allowed uncertainty, missingness reasons, unit handling, correction policies, and lineage. At minimum, test conformance, completeness, and plausibility in a declared verification or validation context [32]. Dataset documentation and model cards can make collection conditions, intended use, and subgroup performance reviewable [27, 28].
  4. Create leakage-safe task views. At every prediction time, expose only information that would truly have been available. Separate model-input, audit-only, and prohibited context; test whether proxies reconstruct a withheld site, future label, or workflow decision. Preserve the transformations that created every view.
  5. Compare against simpler baselines. Test whether the additional context improves calibration, discrimination, decision-curve utility, subgroup performance, clinician time, and error recovery — not only retrospective accuracy.
  6. Evaluate the live workflow. Use silent deployment, usability studies, early prospective clinical evaluation, and then comparative trials when risk warrants. DECIDE-AI addresses early live evaluation [14]; CONSORT-AI and SPIRIT-AI address trial reporting and protocols [13, 15]; TRIPOD+AI addresses prediction-model reporting [16]; STARD-AI adds requirements for AI-centred diagnostic-accuracy studies [37]. The FUTURE-AI consensus guideline extends the view across design, validation, deployment, and monitoring through 30 practices organized around fairness, universality, traceability, usability, robustness, and explainability [36]. Reporting and consensus guidance do not themselves make a study well designed or prove benefit, but they expose omissions.
  7. Manage the total life cycle. Clinical evaluation, risk controls, software maintenance, change management, cybersecurity, drift monitoring, incident response, and retirement must be planned. Relevant anchors include IMDRF SaMD clinical-evaluation guidance, ISO 14971, IEC 62304, ISO/IEC 23894, ISO/IEC 42001, and the IMDRF/FDA good machine-learning-practice principles [21–26]. Two 2026 additions sharpen the data and risk parts of that programme: ISO/TS 24971-2 gives ML-specific guidance for applying ISO 14971 but explicitly excludes LLM and generative-AI devices [38]; IEC PAS 63621 addresses the training, test, and validation-data lifecycle, including traceability, annotation, representativeness, versioning, and validity periods [39]. A technical specification or PAS is not product certification, and neither document replaces clinical evidence.

Conclusion

The interscalar model should not be presented as a universal medical ontology or as a shortcut to trustworthy AI. Its strongest contribution is more modest and more useful: it treats every clinically relevant datum as an event with a time, source, actor, purpose, outcome, uncertainty, and lineage, and it preserves explicit links across the scales at which disease and care unfold.

That architecture can make errors easier to investigate, datasets easier to qualify, decisions easier to audit, and causal questions easier to formulate. It cannot turn correlation into causation, metadata into truth, an explanation graphic into validation, or a patent into clinical evidence. Context itself must be governed because it can function as either a clinical signal, an audit instrument, or a shortcut. The model becomes a foundation for medical AI only when its additional structure is shown — prospectively, across relevant sites and time periods, in a defined workflow — to improve the safety, usefulness, equity, or efficiency of the human–AI system.

References / Список литературы

The English and Russian versions use the same numbered bibliography. All links below lead directly to a publisher record, DOI resolver, PubMed/PMC, an official standards or regulatory body, or the patent document.
Английская и русская версии используют единую нумерованную библиографию. Все ссылки ниже ведут непосредственно к издательской записи, DOI, PubMed/PMC, официальному органу стандартизации или регулирования либо к патентному документу.

Peer-reviewed publications / Рецензируемые публикации

  1. Noble D. “Modeling the heart—from genes to cells to the whole organ.” Science. 2002;295:1678–1682. DOI 10.1126/science.1069881; PMID 11872832. Foundational example of biological multiscale modelling.
  2. Peng GCY et al. “Multiscale Modeling Meets Machine Learning: What Can We Learn?” Archives of Computational Methods in Engineering. 2021;28:1017–1037. DOI 10.1007/s11831-020-09405-5; PMID 34093005. Peer-reviewed review of opportunities and limitations at the multiscale-modelling/ML boundary.
  3. Hsu W et al. “Context-Based Electronic Health Record: Toward Patient Specific Healthcare.” IEEE Transactions on Information Technology in Biomedicine. 2012;16:228–234. DOI 10.1109/TITB.2012.2186149; PMID 22395637; PMCID PMC4414061. Primary prototype, not proof of improved clinical outcomes.
  4. Kawu AA, Hederman L, O’Sullivan D. “Exchanging Context and Provenance Based Standardized Patient Generated Health Data with an Electronic Health Record.” AMIA Annual Symposium Proceedings. 2024 proceedings, posted 2025. PMID 41726536; PMCID PMC12919584. Relevant implementation; authors state that practical clinician evaluation remains future work.
  5. Weiskopf NG, Rusanov A, Weng C. “Sick Patients Have More Data: The Non-Random Completeness of Electronic Health Records.” AMIA Annual Symposium Proceedings. 2013. PMID 24551421; PMCID PMC3900159. Primary evidence that EHR completeness can be informative and biased.
  6. Lewis AE et al. “Electronic health record data quality assessment and tools: a systematic review.” JAMIA. 2023;30:1730–1740. DOI 10.1093/jamia/ocad120; PMID 37390812.
  7. Ghassemi M, Oakden-Rayner L, Beam AL. “The false hope of current approaches to explainable artificial intelligence in health care.” The Lancet Digital Health. 2021;3:e745–e750. DOI 10.1016/S2589-7500(21)00208-9; PMID 34711379.
  8. Rudin C. “Stop explaining black box machine learning models for high stakes decisions and use interpretable models instead.” Nature Machine Intelligence. 2019;1:206–215. DOI 10.1038/s42256-019-0048-x.
  9. Prosperi M et al. “Causal inference and counterfactual prediction in machine learning for actionable healthcare.” Nature Machine Intelligence. 2020;2:369–375. DOI 10.1038/s42256-020-0197-y.
  10. Hernán MA, Robins JM. “Using Big Data to Emulate a Target Trial When a Randomized Trial Is Not Available.” American Journal of Epidemiology. 2016;183:758–764. DOI 10.1093/aje/kwv254; PMID 26994063; PMCID PMC4832051.
  11. Obermeyer Z et al. “Dissecting racial bias in an algorithm used to manage the health of populations.” Science. 2019;366:447–453. DOI 10.1126/science.aax2342; PMID 31649194.
  12. Lyell D, Coiera E. “Automation bias and verification complexity: a systematic review.” JAMIA. 2017;24:423–431. DOI 10.1093/jamia/ocw105; PMID 27516495. See also the simulated e-prescribing study: DOI 10.1186/s12911-017-0425-5; PMID 28302112.
  13. Liu X et al. “Reporting guidelines for clinical trial reports for interventions involving artificial intelligence: the CONSORT-AI extension.” Nature Medicine. 2020;26:1364–1374. DOI 10.1038/s41591-020-1034-x; PMID 32908283.
  14. Vasey B et al. “Reporting guideline for the early-stage clinical evaluation of decision support systems driven by artificial intelligence: DECIDE-AI.” Nature Medicine. 2022;28:924–933. DOI 10.1038/s41591-022-01772-9; PMID 35585198. Parallel BMJ publication: DOI 10.1136/bmj-2022-070904; PMID 35584845.
  15. Cruz Rivera S et al. “Guidelines for clinical trial protocols for interventions involving artificial intelligence: the SPIRIT-AI extension.” Nature Medicine. 2020;26:1351–1363. DOI 10.1038/s41591-020-1037-7.
  16. Collins GS et al. “TRIPOD+AI statement: updated guidance for reporting clinical prediction models that use regression or machine learning methods.” BMJ. 2024;385:e078378. DOI 10.1136/bmj-2023-078378; PMID 38626948.

Official specifications, standards, and regulatory guidance / Официальные спецификации, стандарты и руководства

  1. W3C. PROV-O: The PROV Ontology, W3C Recommendation, 30 April 2013. Normative provenance vocabulary built around Entity, Activity, and Agent.
  2. HL7. FHIR R5 Observation. The resource separates effective time from issuance time and represents subject, encounter, performer, method, and derivation. Observation is normative in FHIR from R4; particular R5 features and profiles must still be checked for implementation maturity.
  3. HL7. FHIR R5 Provenance. Trial-use resource at maturity level 4 in R5; do not describe the whole resource as fully normative.
  4. ISO. ISO 13940:2015 — Health informatics — System of concepts to support continuity of care. A revision was in the publication process when checked on 2026-07-28.
  5. IMDRF. IMDRF/SaMD WG/N41FINAL:2017 — Software as a Medical Device: Clinical Evaluation.
  6. ISO. ISO 14971:2019 — Medical devices — Application of risk management to medical devices.
  7. IEC. IEC 62304:2006 + Amendment 1:2015 — Medical device software — Software life cycle processes. The 2006 edition was confirmed in 2021 and was under systematic review in July 2026.
  8. ISO/IEC. ISO/IEC 23894:2023 — Artificial intelligence — Guidance on risk management.
  9. ISO/IEC. ISO/IEC 42001:2023 — Artificial intelligence — Management system.
  10. FDA / Health Canada / MHRA / IMDRF. Good Machine Learning Practice for Medical Device Development: Guiding Principles. These are guiding principles, not a certification or proof of compliance.

Technical documentation articles / Публикации о документировании моделей и данных

  1. Mitchell M et al. “Model Cards for Model Reporting.” Proceedings of FAT* ’19. DOI 10.1145/3287560.3287596.
  2. Gebru T et al. “Datasheets for Datasets.” Communications of the ACM. 2021;64(12):86–92. DOI 10.1145/3458723.

Patent documents / Патентные документы

These documents describe prior art and are not clinical evidence.
Эти документы описывают предшествующий уровень техники и не являются клиническими доказательствами.

  1. US 2022/0215961 A1, “Clinical decision support”, published 2022-07-07. Describes selecting subject-specific information and UI elements using clinical context. The US application is listed as abandoned; family members have different statuses.
  2. US 2020/0051698 A1, “Precision clinical decision support with data driven approach on multiple medical knowledge modules”, published 2020-02-13. Describes comparing rules with historical outcomes and ranking applied rules. Patent claims and legal status require a separate legal review.
  3. US 12,021,967 B2, “Privacy preserving artificial intelligence based clinical decision support”, granted 2024-06-25. Describes homomorphic processing of medical data. This is relevant to a privacy-risk discussion, not evidence that privacy-preserving inference is clinically useful in a particular workflow.

Additional sources verified on 2026-07-29 / Дополнительные источники, проверенные 29.07.2026

Peer-reviewed publications / Рецензируемые публикации

  1. Kahn MG et al. “A Harmonized Data Quality Assessment Terminology and Framework for the Secondary Use of Electronic Health Record Data.” eGEMs. 2016;4(1):1244. DOI 10.13063/2327-9214.1244; PMID 27713905; PMCID PMC5051581. Defines conformance, completeness, and plausibility in verification and validation contexts.
  2. Zech JR et al. “Variable generalization performance of a deep learning model to detect pneumonia in chest radiographs: A cross-sectional study.” PLOS Medicine. 2018;15(11):e1002683. DOI 10.1371/journal.pmed.1002683; PMID 30399157; PMCID PMC6219764. Primary multicentre evidence of site-dependent generalization and hospital-system confounding.
  3. DeGrave AJ, Janizek JD, Lee S-I. “AI for radiographic COVID-19 detection selects shortcuts over signal.” Nature Machine Intelligence. 2021;3:610–619. DOI 10.1038/s42256-021-00338-7. This is the peer-reviewed version of the earlier medRxiv record; the journal DOI, rather than the preprint DOI, is cited here.
  4. Wong A et al. “Multicenter Prospective Validation of an Updated Proprietary Sepsis Prediction Model.” JAMA Network Open. 2026;9(2):e260181. DOI 10.1001/jamanetworkopen.2026.0181; PMID 41758510; PMCID PMC12949446. Prospective external evaluation at four health systems; improved discrimination coexisted with site variability, low positive predictive value, and high alert burden.
  5. Lekadir K et al.; FUTURE-AI Consortium. “FUTURE-AI: international consensus guideline for trustworthy and deployable artificial intelligence in healthcare.” BMJ. 2025;388:e081554. DOI 10.1136/bmj-2024-081554; PMID 39909534; PMCID PMC11795397. The separate erratum record is DOI 10.1136/bmj.r340; PMID 39961614.
  6. Sounderajah V et al.; STARD-AI Steering Committee. “The STARD-AI reporting guideline for diagnostic accuracy studies using artificial intelligence.” Nature Medicine. 2025;31(10):3283–3289. DOI 10.1038/s41591-025-03953-8; PMID 40954311. Author correction published 2026-07-13: DOI 10.1038/s41591-026-04570-9; PMID 42443516.

Official standards / Официальные стандарты

  1. ISO. ISO/TS 24971-2:2026 — Medical devices — Guidance on the application of ISO 14971 — Part 2: Machine learning in artificial intelligence. Published 2026-06. Its official scope covers ML-enabled medical devices and explicitly excludes devices employing LLMs or generative AI.
  2. IEC. IEC PAS 63621:2026 — Artificial intelligence enabled medical devices — Data management. Edition 1.0, published 2026-03-18. A Publicly Available Specification for training, test, and validation-data lifecycle processes; its status is not the same as a full International Standard.

Patent documents / Патентные документы

  1. US 11,929,176 B1, “Determining new knowledge for clinical decision support”, granted 2024-03-12. Claims include learning a decision epoch before a probable clinical event from codified concepts and sensor indications. Patent scope and legal status require professional legal analysis.
  2. US 2025/0266170 A1, “Artificial intelligence architecture for providing longitudinal health record predictions”, published 2025-08-21; application listed as pending when checked. Describes mapping longitudinal event records and contextual features to a vocabulary with time-interval tokens for sequence-to-sequence prediction. It is prior art, not evidence of clinical performance.