The next generation of medical AI: a dynamic model of health

About the paper

The text below presents the conference paper delivered by Margarita Pirinen, founder and CEO of BIOS, at the 13th Russian Biotechnology Forum OpenBio 2026 in the science town of Koltsovo.

The presentation formed part of the expert session ‘Technologies and products of Russian and international biotechnology: what is available to the Russian market right now’. Its title was ‘The next generation of medical AI: a dynamic model of health’.

Purpose of the paper — to set out a direction for the next generation of medical AI: from individual documents and measurements to a dynamic model of a person's health. Using BIOS as an example, it shows how to begin building the technological foundations for medicine that preserves a continuous personal history, tracks changes and, in time, models health trajectories.

Key objectives: to consider a person's condition over time as an object of computation; to connect a fundamental research hypothesis with working products and business economics; to establish architectural principles that allow technologies to evolve without losing accumulated data and knowledge; and to specify what must be demonstrated before modelling states and their changes. The overarching question is how Russian biotechnology can establish its own technological directions and develop solutions for problems the market has not yet articulated.

Technological sovereignty begins with infrastructure

This paper treats technological gaps, particularly in biotechnology, as a systemic problem that cannot be reduced to the absence of a single instrument, reagent, software package or investor.

When discussing the technological infrastructure of Russian biotechnology, we face concrete questions: which solutions are already available to laboratories; how to ensure comparable, reproducible results; how to connect equipment from different manufacturers, software and data; and how to bring strong research developments into everyday practice.

One further question belongs on this agenda: how can solving today's problems also build tomorrow's technological infrastructure?

This paper defines technological sovereignty as the ability to identify independently the next class of technologies required, create it, demonstrate that it works and integrate it into the real economy. Domestic alternatives are necessary, but do not exhaust that task.

This argument is developed through BIOS. The author, Margarita Pirinen, is the founder and CEO of the company developing BIOS and the author of the technology, which at OpenBio became an award winner in the Scientific Community's Choice competition. This recognition matters especially to us: BIOS began as a research hypothesis, but we never built it as research for its own sake.

BIOS is a business. Over the past few years, we have been addressing a practical question: can we develop a sufficiently fundamental technology for medicine's next development cycle while already turning it into products used by doctors, clinics and patients? Combining these aims calls for a different approach to innovation and infrastructure.

1. There is no shortage of technology today

Work on BIOS has involved encountering dozens of related projects in accelerators, competitions and technology programmes, as well as mentoring several solutions in adjacent fields. This experience has made it possible to compare different approaches to developing medical technologies and bringing them to market.

Our experience with BIOS suggests that the problem is not so much a shortage of products as their disconnectedness. Solutions range from a few hundred roubles to several thousand and enterprise platforms: laboratory data interpretation, medical assistants, device integrations, document aggregators and decision-support systems.

A paradox remains: demand exists, developments and scientific findings are plentiful, yet the path to sustained use is still difficult. The problem must run deeper than the absence of a solution.

One possible reason is the separation of research and entrepreneurial thinking. A researcher must create something fundamentally new; an entrepreneur must discover what the market wants to buy today. Each logic is sound independently, but separating them becomes a constraint in biomedical technology.

The market can describe its current problem very well. It is not obliged to articulate the architecture of a technology that will solve that problem in five or ten years.

If a doctor says, ‘It takes me too long to understand a patient's history,’ an excellent document search tool could address that immediate need. But the question can be taken one level deeper: why must doctors manually reconstruct a patient's condition from separate documents every time?

We then begin designing a different system: not a tool for finding information faster, but infrastructure that preserves continuous context about a person's condition. This distinction between treating a local symptom and addressing its cause became one of our central design principles for BIOS.

Three generations of HealthTech within the evolution of artificial intelligence

This paper distinguishes three HealthTech generations according to the technological task a system addresses: digitising medical practice, extracting meaning from data or modelling a person's condition over time. The sequence helps explain the BIOS architecture and its place in medical AI. These generations coexist: new models operate on top of digital infrastructure, and one platform may combine capabilities from several stages.

HealthTech 1.0: digitising medicine

The first major task was to turn medical information and workflows into digital form. Paper charts become electronic records, individual forms become results in laboratory systems, and film becomes a digital image archive. Appointments, prescriptions, billing, document exchange and patients' access to their histories become software functions.

This generation is founded on databases, storage systems, patient identification, exchange interfaces and access management. Medical information systems, laboratory information systems and image archives address different parts of the problem. Connecting them requires aligned formats, terminology and identifiers: does a record belong to the same person, what was measured, in which units and when? Integration quality already determines whether the data can later support computation.

Products in this category are familiar. In Moscow, the electronic record in EMIAS provides access to examination notes, laboratory results and discharge summaries. The Russian medical information system MEDODS combines appointments, medical records, consultation notes, test results and laboratory workflows. The patient portal MyChart provides access to results, medications, appointments and medical information exchange. This comparison concerns digitisation functions, not the full capabilities of these evolving platforms.

Wearables extend this layer by adding everyday measurements to clinical data. They produce time series of activity, heart rate and other signals. Collecting and displaying them does not yet mean a system can explain changes in health, but supplies material for the next stage.

The basic unit of this generation is a digital record of an event. The system knows that an appointment occurred, a test result arrived or a prescription was issued. It may store them together, but doctors often reconstruct the clinical relationships themselves. A complete electronic record and a coherent model of a person's condition are different technological outcomes.

Digitisation solved the problem of availability while increasing the volume of information to be processed. A person's history accumulates documents from different specialties, results from different laboratories, repeat examinations and device data. The longer the history, the more effort it takes to identify what matters and connect events. The next task follows: the data is available; now it must be processed and interpreted.

HealthTech 2.0: generative AI and automated analysis

The next task is to automate work with the content of medical information. Two connected directions emerge: specialised algorithms for specific tasks, and models adaptable to many tasks. Medicine gains tools for recognising images and signals, assessing risks, extracting facts, preparing documents and conversing with users.

The evolution of AI explains why these tools differ. Expert systems execute human-defined rules. Classical machine learning identifies relationships in prepared features. Deep neural networks learn features directly from images, text and signals. One model may detect signs of disease in an image, another analyse an ECG, and a third calculate risk from a set of measurements. The development of these applications is described in Eric Topol's review of medical AI.

In a specialised task, developers define the inputs, target variable and quality criterion in advance. A new task often requires different labels, tuning and validation. High accuracy in recognising one feature does not mean the algorithm can interpret an entire patient history.

The next major shift in AI involves foundation models. Large-scale pretraining builds representations that can then be adapted to different tasks. In self-supervised learning, the training signal comes from the data itself: for example, a model reconstructs hidden portions of text or an image. This reduces the pretraining stage's dependence on manual labelling for each clinical task.

The Transformer architecture and its attention mechanism, which captures relationships between sequence elements, played an important role. A foundation model need not be linguistic or generative, however: reusable representations can be learned from images, physiological signals and combinations of modalities. In medicine, this enables joint work with text, images and measurements, as well as transfer to tasks with limited labels — a direction set out in Moor and colleagues' paper on generalist medical AI.

One concrete example is RETFound: self-supervised pretraining on retinal images provides a basis for adaptation to disease-detection tasks. This changes the economics of training: part of the representation is learned in advance and reused, although each medical application still requires its own quality assessment.

At product level, this can be seen in Microsoft Dragon Copilot: AI helps prepare clinical documentation, which the doctor reviews and completes. This is a specific automation of language and medical-content processing embedded in a workflow.

Systems also gain external-source retrieval — retrieval-augmented generation, or RAG — and tool integration. A model can retrieve relevant documents, call computational modules and answer using the retrieved context. This extends the interface's capabilities but creates separate engineering challenges: retrieval completeness, source currency, correct fact extraction and verification of actions performed.

Another example from our competitor map is PatientGPT by K Health: conversations with patients are linked to their medical records and the organisation of subsequent care. The model's integration into the clinical pathway matters as much as its answer. The second generation therefore cannot be reduced to isolated chatbots: products are progressively incorporating context, tools and interaction with doctors.

This stage's main advance is algorithms' ability to interpret medical data; foundation models can also reuse learned representations. These representations may support many tasks and long sequences. The next generation's boundary therefore cannot be defined merely by time, memory or a large context window: contemporary models may already have all three. For us, the next step concerns how the whole system is organised and what it is intended to model.

Why generative AI alone is not enough

Connecting a language model to an electronic record seems natural: it reads documents, extracts facts, prepares summaries and answers questions. But learning to predict text continuations does not itself establish the truth of every medical claim or the rules for maintaining a patient history. These properties must be ensured by the system as a whole.

The first problem is hallucinations and omissions. A model may add an absent fact, misrepresent a negation or omit an important detail when summarising a history. In a paper by Asgari and colleagues in npj Digital Medicine these errors are assessed separately with regard to clinical risk. The authors show that quality depends on the workflow configuration: an additional processing step does not necessarily improve the result. Medical applications must evaluate both what a system says and what it leaves out.

The second problem is memory. A context window contains information for the current computation, but does not itself determine what to retain between visits, how to account for corrections or when to revise a previous conclusion. Repeated summarisation is no substitute for medical memory: successive compression can lose a source, date, qualification or relationship to a prescription. ‘Intelligent memory’ here means a managed history of facts and changes, not merely a saved conversation.

The third problem is computational organisation. If every answer requires reprocessing a large archive, reading and retrieval costs grow with the history. Yet calculating trends, checking units and interpreting text are different kinds of work. A language model need not perform every operation. The system must establish which data has already been processed, which calculations are reproducible and which new events genuinely require reassessment.

Modern systems address these limitations through retrieval, external memory, tools and verification mechanisms. Progress therefore involves more than replacing one model with another. The next question is what object should organise this work so that each new interaction continues the medical history rather than restarting its interpretation.

HealthTech 3.0: modelling health over time

In this classification, the third generation is defined by its task, not an algorithm's name. A system must maintain an updatable model of a person's condition, incorporating accumulated history, new observations, their acquisition conditions and uncertainty. The further research task is to describe patterns of change and test predictions against subsequent observations.

We understand health state as a computable representation of a person at a particular moment, built from available data. It includes observed measurements, their relationships and trajectories, significant events and interventions, and information gaps. It is not a single ‘health index’ or a list of diagnoses. Two people with the same current measurement may have different baselines, directions of change and measurement conditions — and therefore different contexts for assessment.

Scientifically, this is a problem of reconstructing a partially observed dynamical system. We do not measure the whole organism: different tests provide incomplete observations at different times. Physiological dynamics must be distinguished from the way they are observed. More tests, for instance, may reflect more intensive monitoring rather than worsening health. The model must consider timing, missingness and data provenance, not just values in a table.

This formulation is illustrated well by PULSE, a paper by Wu and colleagues in Nature Computational Science. The authors combine a personalised previous state, Past-State, with incomplete current measurements to form Visit-State. In the tasks studied, history helps reconstruct missing modalities and build predictive features. Here, state is a learned latent representation, demonstrating that a third-generation task does not require a single, necessarily neuro-symbolic architecture.

Reconstructing a state from incomplete data

In our architecture, incomplete data becomes part of the model. We reconstruct state components for which there is evidence, retain uncertainty and identify information needed for refinement. The doctor receives not merely an incomplete set of documents, but an account of what is known and where the specific gaps lie.

Two operations must be distinguished. The first connects existing facts and reconstructs the accessible part of a state. The second estimates an unobserved quantity using a trained model. Such an estimate is retained with its method and uncertainty and does not replace an actual test. Reconstruction means extending an evidence-supported representation of a person, not filling every empty field with plausible numbers.

Assessing a change may require a missing baseline, a comparable repeat measurement, the date of a treatment change or information on testing conditions. Data may be outdated or contradictory. We identify the gap relative to a particular task: what cannot be reconstructed confidently and which information could clarify it.

The next step is to compare possible observations by how much they may reduce uncertainty. This requires a model of likely outcomes and their effect on the state estimate. Information value must be weighed against clinical appropriateness, risk, availability and cost. The system thus helps formulate the next question, while the decision to order an examination remains with the doctor.

What a state model changes in practice

Consider a hypothetical scenario: a person has several years of laboratory results, then treatment changes and new measurements arrive. A digital archive displays the documents. An AI assistant can prepare a summary. A state model must also connect the measurements to the preceding trajectory and intervention, check comparability, identify changes and show which conclusions now need revision.

This enables more substantive questions. Is a measurement changing relative to the individual's baseline? Is its trajectory consistent with other observations? What information is missing to distinguish a persistent change from measurement variability? Which parts of the previous description are no longer current? Doctors need these answers to choose the next monitoring step; researchers need them to formulate testable hypotheses.

A more complex level involves prediction: how might the state change under specified conditions and interventions? Expected trajectories, observed changes and causal effects must be distinguished. The sequence ‘prescription — measurement change’ does not establish a treatment effect. Such conclusions require appropriate data and study design.

The significance of this transition is that medicine can address changes in health, rather than only the result of one examination. This provides a basis for personalised monitoring, earlier detection of meaningful shifts and testing responses to interventions. The new model does not replace diagnostics; it should connect individual diagnostic events into a process that can be studied systematically.

Within the broader evolution of AI, several directions meet here: time-series and latent-state models, multimodal representations, graph methods, mechanistic models, neuro-symbolic systems and operator learning. A broader combination of models across biological scales is discussed internationally in the AI-driven digital organism programme. The choice of technology depends on what we reconstruct, what we predict and which constraints we can test.

Our approach: the hybrid BIOS architecture

This is the architecture towards which BIOS is strategically moving. Its task is to connect medical memory, state reconstruction and the study of dynamics into a single system that develops as data and knowledge accumulate.

At BIOS we have chosen a combination of methods. Neural components process heterogeneous data; medical memory preserves history; symbolic rules and a knowledge graph provide explicit relationships and checks. Dynamic models address a different task: describing state changes. A hybrid architecture lets each operation use an appropriate computational method, instead of asking one language model to store history, know medicine, calculate and predict simultaneously.

The neuro-symbolic approach is one part of this solution. It combines learning from data with explicitly represented knowledge and reasoning procedures; this combination is the subject of Neurosymbolic Learning and Reasoning. For us, its value is the ability to separate a probabilistically proposed interpretation from formally verifiable evidence.

How functions are distributed within BIOS

Our architecture separates functions that can easily become conflated in an ordinary model conversation. Reading a document, storing a fact, calculating a change, proposing a hypothesis and explaining it to a doctor are five different operations. Each needs its own inputs, rules and output checks.

1. The neural layer extracts information. Text, images or signals are converted into features and candidate medical facts. A laboratory form, for instance, requires extraction of the measurement name, value, units and date. Recognition errors are possible at this stage, so the extracted value must remain linked to the original document.
2. Medical memory provides context. An observation takes its place in the history alongside its source, time and available measurement conditions. A doctor's correction must not erase the previous record without a trace. Missing data is recorded as unknown: if a symptom is not mentioned, its absence cannot be assumed.
3. The symbolic layer establishes meaning and constraints. An ontology describes medical concept types and permissible relationships, a graph connects specific information, and rules define conditions for comparison and inference. Checks include unit compatibility, event order and the presence of required inputs. ‘Measured after a prescription’ must not automatically become ‘changed because of the prescription’.
4. The computational layer produces a state version. We treat state as a distinct object: which observations were used, which changes were detected, what remains unknown, and which rule and model versions produced the result. When a new test arrives, the system must identify which parts of the representation need updating and preserve the grounds for revision.
5. The language interface explains the result. An LLM helps formulate responses and interact with computational tools. Answers are grounded in stored facts and check results. A clinical hypothesis must be presented as a hypothesis; an unsupported claim must not be represented as an established fact.

This is the distinction between document retrieval and a neuro-symbolic system. RAG selects text for a model to use in answering. Our architecture must also store typed facts and their dependencies, apply formal checks and track which conclusions change when data is updated. The graph may assist retrieval, but its principal value for us lies in explicitly representing medical context and the basis for computation.

Determinism applies to specific operations: identical inputs and rule versions must produce identical check results. A probabilistic model estimates uncertainty, a formal layer checks defined constraints, and a doctor assesses clinical meaning. This separation allows each component's errors to be studied rather than judging the system solely by how convincing its final text sounds.

A cumulative knowledge graph and result verification

An individual's memory must be separated from the general medical knowledge base. Memory stores observations, documents and events from that person's history. The knowledge graph stores medical concepts, relationships and rules with conditions of applicability. A graph relationship does not itself become a fact about a patient: applying it requires appropriate data from their history.

At BIOS, the research process is separate from conversations with patients. It follows scientific publications, guidelines and other sources, checks document provenance and versions, and extracts claims together with their conditions and limitations. Evidence is stored in a registry and relationships in a research graph. New information may support a hypothesis, weaken it, narrow its applicability or leave it with an ‘insufficient data’ status. Previous versions are retained.

A guideline, an official classification and an individual study provide different kinds of evidence. Copies of one publication do not count as independent corroboration, and contradictory data is not removed to produce a single answer. Moving knowledge from the research graph into an applied rule is a separate procedure that considers the claim type, source, version and conditions.

Knowledge accumulation therefore does not require the conversational model to declare its own answers true. Its proposal can be examined through the research process, but must not automatically become a rule for verifying subsequent answers. We need to avoid circular confirmation in which a system invents a relationship and then cites it as evidence.

The deterministic verification mechanism applies fixed rules to data. It may detect incompatible units, a missing required condition or a contradiction between a claim and its source. With identical inputs and rule versions, the check is reproducible. This makes the graph a control instrument, while the completeness of its knowledge and the clinical correctness of its rules remain separate research questions.

A related but different approach is illustrated by InfEHR, published in Nature Communications: a medical history is converted into a temporal graph, on which representations are learned for probabilistic inference with few labelled examples. This is not the same mechanism as deterministic rule checking. The example matters because how a history is organised affects training requirements and subsequent analytical possibilities.

Why the entire system need not be retrained

We do not make lengthy language-model retraining a prerequisite for every update to medical knowledge. A pretrained model is used where its linguistic and perceptual capabilities are needed. A newly confirmed relationship can enter the external knowledge base, a rule can enter the verification mechanism, and a new observation can enter the patient's memory. These changes do not necessarily require changing neural-network weights.

These are three separate processes: model training changes parameters; research expands and refines knowledge; state updating applies available methods to a new observation history. Separating them allows capabilities to grow without repeating a full training cycle after every change. Data and knowledge verification still require work, but that work becomes targeted and traceable.

We relate accuracy to the quality of this entire sequence: was the fact extracted correctly, was the rule applied properly, and is there sufficient evidence for the conclusion? Graph-based verification should constrain certain error classes. Demonstrating gains in quality and efficiency requires separately defined measures: extraction accuracy, critical omissions, unsupported claims, processing time and update cost. This will allow us to assess the graph, memory and models by outcomes rather than persuasive language.

Neural operators: a separate task of modelling dynamics

Neural operators complement this architecture from another direction. A knowledge graph helps verify evidence and constraints; an operator model learns transformations between functions, such as mapping specified conditions to a modelled system's trajectory. In the Fourier Neural Operator paper this approach was studied on families of differential equations, including fluid dynamics problems.

For BIOS, this is a research direction for state transitions. Rather than an isolated answer about today's measurements, we are interested in reproducible patterns of change under specified conditions. An operator also requires training. Its potential value is in reusing learned relationships within their domain of applicability, not in dispensing with training data. This hypothesis is examined in detail in the neural operators section.

The hybrid thus connects different kinds of work: a neural network extracts a representation, memory preserves history, a graph constrains admissible interpretations, a computational model describes state, and an operator approach investigates its dynamics. We can change and test these components separately while preserving their common object: a person and their history.

The practical purpose of this distinction is to understand what we are building and how its results will be assessed. A digital archive needs completeness and availability. An individual model needs to perform its task well. A system that accompanies a person over time also needs stable context, correct revision of conclusions and evaluation against future events.

Where BIOS fits

The transition from the first to the second generation is visible in how product tasks are framed today: a digitised history must be read, condensed, searched and used to prepare an answer. From the outset, BIOS was given a third-generation task — modelling state over time — and we chose a hybrid architecture to address it. In BIOS, the object of work is a person with an evolving history, around which individual models and products are built.

A hypothetical scenario makes the distinction clearer. A person brings several years of test results. A first-generation system stores them and provides search and access. A second-generation system uses pretrained representations to extract measurements, summarise the history and support different tasks. In the third generation, the task continues: a new result must update the overall history, preserve relationships with prescriptions and previous measurements, and show meaningful changes and grounds for further checks. This is the sequence we are building into BIOS. State-transition modelling is the architecture's next research layer.

What creates a technological advantage

For BIOS Personal, Doctor and Clinical, this means using a shared medical memory through different interfaces. Patients need to understand changes and prepare for appointments; doctors need to reconstruct events and verify evidence; clinics need continuity of monitoring. Research use adds protocol, consent and access-control requirements. We want to avoid rebuilding a separate representation of a person for every product.

The first advantage is independence of accumulated knowledge from a particular neural network. If facts, relationships and state versions are stored separately, an extraction model or language interface can be updated without recreating the entire medical history. This reduces architectural dependence on a single model's lifecycle.

The second is the ability to update computations in response to changes. A new document does not always require reanalysing the entire history. Explicit dependencies identify affected calculations and conclusions. Where a new observation changes the interpretation of old data, recalculation must include it. Practical gains are measured in processing time and update cost while preserving quality.

The third is reusing knowledge and components across tasks. Normalising a measurement, placing it in time and checking comparability are necessary for patient services, doctors and research protocols alike. We expect to reduce repeated engineering work. A reduced need for specialised training data is a separate hypothesis that must be tested by comparing models.

The fourth is research reproducibility. Retained sources, versions and boundaries of what is known allow us to reconstruct the basis of a result at a particular time. Methods can be compared on the same history, component contributions tested, and information that appeared only after the evaluated event excluded. For science, this matters as much as predictive accuracy.

The anticipated long-term advantage lies in accumulating the results of this work. Changing a language model should not reset medical memory. Connecting a laboratory should extend available observations. Testing a hypothesis should leave a reproducible method for the next task. Each new product inherits a foundation that would otherwise have to be rebuilt.

This foundation could provide an advantage for years: its value comes from aligned data, verified relationships, evaluation protocols and implementation experience. Our test of it is concrete: demonstrate that, as the system develops, the next source is easier to connect, a new task requires less repeated development and quality survives transfer. These outcomes will express our advantage.

For science, this enables the study of sequences of changes, a return to original observations and comparison of hypotheses on the same history. For medical practice, it preserves continuity between specialists and stages of monitoring. For individuals, it avoids having to tell their health story from the beginning at every consultation.

2. The unit of analysis is already changing worldwide

This is not only our hypothesis. International research shows a sustained movement from individual measurements towards longitudinal representations of people.

In July 2026, Google Research introduced SensorFM, a model trained on more than a trillion minutes of wearable data from five million people. It works with long physiological sequences rather than isolated heart-rate or activity measurements and transfers the learned representation to dozens of health-related tasks.

In September 2026, Nature Medicine published a study reconstructing computable longitudinal patient trajectories from structured data and ordinary clinical notes. The researchers reconstructed measurement changes after treatment began, treating them as a continuous process over time rather than isolated points.

The object of computation is gradually changing: a person over time, together with their measurements, documents and appointment history. This is a fundamental change in how the problem is framed.

The organism is a dynamic system, while much of medical infrastructure is still designed to record separate events. A laboratory obtains a value, a doctor writes a conclusion, a patient undergoes a test, treatment is prescribed. Three months later comes another point. Yet the biological system does not stop between those points: it continues to change.

3. This is where BIOS began

When designing BIOS, we placed at the centre of the system a person's condition and its change over time. Documents, tests, diagnoses and individual product functions must serve that task. This was the starting point for our architecture.

We have many heterogeneous observations: laboratory values, medical documents, history, prescriptions, symptoms, study data and, in the future, wearable data and other sources. BIOS's task is not simply to assemble them on one screen.

Each observation, its provenance, time and context must first be preserved and integrated into a continuous personal history. A new observation is then compared with previous ones to establish what has actually changed, moving gradually from separate events to state reconstruction, state comparison and trajectory analysis.

In practice, this complex architecture should deliver a simple result. The system should help answer four questions:

• What is the person's current condition?
• What has changed significantly?
• What trend can be observed?
• What information is still insufficient for a more confident assessment?

The more complex the underlying technology, the simpler the user experience should become. Doctors should not have to operate a complex computational system. They should receive a more coherent context sooner and with less cognitive effort.

What we mean by a person's state

The object of work needs clarification. A person's state cannot be reduced to a diagnosis or a set of measurements on a form. We see only available observations: tests, symptoms, prescriptions, measurements and doctors' descriptions. From them we can construct a more or less complete representation of what is happening, but confidence depends on the quality and completeness of the history.

Time has a distinct role in this model. For the same fact, the event date, measurement date and date a document entered the system may differ. A prescription may have been cancelled, a result revised or a symptom recorded retrospectively. If these distinctions are lost, a carefully written summary can still present the wrong event sequence.

Medical memory must therefore preserve both facts and the history of their refinement. A new record may extend an earlier one, contradict it or change its meaning. The system must show what supports the current representation, which relationships have been established and where data is insufficient. This is the necessary basis for further modelling of dynamics.

Consider a hypothetical example: a new laboratory result enters the history. Comparing it with a previous result requires units, method, sample-collection time and prescriptions between the measurements. A numerical change alone does not explain its cause. The system's job is to preserve this sequence and help the doctor test possible explanations.

Why the architecture needs several computational layers

In the BIOS presentation, the language model occupies the interface layer: it helps formulate questions and present answers. Its capabilities are also useful for text processing, but medical-history storage, date and unit comparison, source control and research into state transitions need their own verifiable mechanisms.

A hybrid approach separates these tasks so each can be tested independently. A model that writes a good summary may still reconstruct the chronology incorrectly. A prediction accurate in one group does not establish transferability to another clinic. Further development requires knowing which component produced a result and where an error arose.

This separation also concerns data governance. Different participants need different access rights; results must retain provenance and changes must be traceable. Developing a shared technology core does not mean medical data can flow freely between every product and organisation.

4. We deliberately chose a riskier path

When we started BIOS, it would have been much easier to follow a familiar product path: build a laboratory-test interpreter, focus on one data category or create a medical assistant. Choose one function that is easy to explain to the market and improve it steadily.

We were repeatedly advised to do exactly that: narrow the scope, simplify and postpone the complex architecture. Earn revenue from a straightforward product first, and build the fundamental technology later.

We deliberately took a different risk: keep the destination fixed while remaining free to change the route. We can change user scenarios, the order of product launches, the commercial model and integrations. But if our ultimate object is a person's condition over time, every product released today must also become part of that future system.

Otherwise, in a few years we could have a commercially successful collection of features that must be entirely rebuilt to create the technology for which the company was founded.

5. Why this risk makes economic sense

At first glance, a fundamental architecture means a longer, more expensive path. Over a longer horizon, however, it should have the opposite effect.

We are building a system of relatively independent computational and product modules that share a common approach to data and state. A new product therefore need not mean a new system. It can be a new combination of existing components.

Today, one combination forms a product for doctors, another for patients. Other combinations may serve laboratories, research or specialised clinical scenarios.

The architecture becomes a business asset in its own right. We build value not only in the interface and accumulated dataset, but in how state is represented, changes are processed and components interact. This is much harder to copy than a product's exterior.

One technology base — four use cases

The presentation describes four directions: Personal, Doctor, Clinic and Research. Patients need a personal health history and an understanding of changes. Doctors need clinical context, structured data and testable hypotheses. Clinics need continuity between appointments and specialists. Research requires high-quality longitudinal data, defined outcomes and reproducible cohort analysis.

These scenarios place different demands on interfaces, access and quality assurance. Shared architecture avoids rebuilding source, time and relationship processing for every product. Launching a research use case still requires separately organised data handling, appropriate grounds and a protocol; it does not follow automatically from having a patient application.

Evaluating the economics of such a system requires measuring reuse: how many components served the next product, how long a new source took to integrate, and what changed when moving to another clinic. These measures help establish whether the architecture genuinely becomes an asset that reduces future development costs.

6. From state assessment to patterns of transition

Another technological layer is fundamental to us: neural operators. This has been a strong direction in scientific computing in recent years. Anima Anandkumar and her team at Caltech have played a major role in its development.

Neural operators were initially developed to model complex physical systems. Their central idea is to learn not just a correspondence between two fixed sets of parameters, but a transformation operator: a pattern by which one function or state maps to another. In scientific computing, this enables work across spatial resolutions and, in some tasks, substantially accelerates the solution of complex physical models. This has already been demonstrated in fluid dynamics and other systems described by differential equations.

Our aim is not to transfer a method mechanically from physics to medicine, but to transfer the way the problem is formulated. If health is a dynamic system, the question is not only whether its current state can be classified. We want to know whether we can formalise patterns of transition from state A — under specified conditions and interventions — to state B.

This is a considerably harder research task, and the one we intend to test systematically. If the hypothesis is confirmed, it could have practical consequences: a new task might no longer require training a separate system from scratch on an enormous specialised dataset each time.

We could reuse an existing representation of dynamics and adapt individual modules. This should reduce the specialised data required and therefore the time and cost of training.

Modularity allows individual parts to be replaced and reconfigured without recreating the whole platform. Incremental processing of state changes should reduce redundant computation and improve processing speed. Separating computational components enables more flexible arrangements for storage, access and processing, and avoids a single critical point in the system.

A clear distinction is necessary here: these are our technological hypotheses and the architecture's expected advantages. In medicine, mathematical elegance is not enough. We need experimental evidence that the architecture requires less data, improves accuracy, works faster and retains quality across different patient groups on specific medical tasks. This is where BIOS's scientific work begins.

7. What this changes for laboratory infrastructure

The same principle applies across the sector. A laboratory can combine ten excellent instruments, several information systems and dozens of data sources. But the number of technologies does not itself create infrastructure.

Infrastructure emerges when the output of one element becomes a usable input to the next. When results can be compared and data provenance preserved; when replacing an instrument does not reset a patient's history, and a new module can be connected without rebuilding the whole system.

Data must not become locked inside one vendor's system. A technological solution should create a cumulative asset, not another isolated island.

The approaches described in WHO SMART Guidelines explicitly include standardised, machine-readable and reusable components, interoperability and reduced dependence on a single vendor. The logic is the same: resilience lies not in a closed application itself, but in a system whose components and data can interact and be updated without dismantling the entire infrastructure.

8. What to choose today and what must be demonstrated

When selecting a laboratory solution, it is important to assess not only the product but also the architectural consequences of adopting it. Several questions need answers:

• Can you retrieve your data?
• Is its provenance preserved?
• Are results comparable over time?
• Can a component be changed without a complete migration?
• Is there an open interface for interacting with other systems?
• Can the solution scale?
• Does today's choice create more possibilities tomorrow, or create a new technological dependency?

Comparing solutions requires more than their purchase price. For example, BIOS Doctor costs a doctor RUB 2,490 per month and requires no separate equipment.

A technology's true cost is more than its licence. It includes integration, training, support, professional time, the cost of errors, data migration and eventual replacement. A cheap solution today may become the most expensive in three years if the infrastructure has to be rebuilt.

Finally, what already works and what still requires evidence? Working functions must be distinguished from research tasks. BIOS already has an operational application layer: collection and structuring of medical data, continuous medical memory, work with longitudinal context, and products for doctors and patients.

A formal model of states, transitions and trajectories is the next research layer. For this layer, we must demonstrate accuracy, robustness, transferability, computational efficiency and clinical relevance. A technological hypothesis becomes a technology only after such evaluation.

The global agenda: tasks shaping the next cycle

Across biotechnology, a dynamic health model forms part of a broader agenda. Researchers work at different scales, from molecules and cells to organisms and multi-year personal histories. The central question is how results at these levels will connect and become available to the next research task.

1. A computable human state

SensorFM and longitudinal clinical-trajectory studies demonstrate two routes: continuous everyday signals and histories of medical events. The next question is how to align these streams, account for missing data, distinguish persistent change from random fluctuation and test predictions against future observations.

This is BIOS's principal focus. We want to connect observations to history, history to a representation of state, and then investigate patterns of change. A practical example is preparation for a follow-up appointment: doctors need to see what happened after their previous decision, what information has arrived and what remains missing for a conclusion.

2. Genomics in the context of clinical history

In September 2026, Google DeepMind introduced AlphaGenome Atlas — predictions of the functional effects of nine billion possible single-nucleotide variants in the human genome. This is the scale of computational variant analysis, not a count of people examined. The authors explicitly state that the tool has not been validated for clinical use.

This example raises the next question: how can a molecular hypothesis be connected to what is actually observed in a person over time? A variant alone does not describe a whole health history. Research requires clinical manifestations, conditions, age, interventions and subsequent outcomes. In the future, the BIOS architecture should support such data while preserving provenance and confidence levels. Genomic predictions still need their own validation.

3. Cellular models and connections across scales

The paper by Bunne and colleagues on the virtual cell considers combining heterogeneous cellular data into models for studying biological processes and responses to perturbations. This framing brings connections between levels of biological organisation to the foreground.

Song, Segal and Xing set out a research programme of related scope in their paper How to build an AI-driven digital organism: connected models of molecules, cells and organisms should support prediction and guide experiments. This is a development programme, not an already completed universal digital organism.

BIOS works at another level: a person's history and state. Nevertheless, we need to design for connecting clinical observations with findings from such research. A hypothesis about a cellular mechanism, for example, could be compared with changes in observed measurements. This requires compatible data descriptions and separate validation of the links across scales.

4. Computational molecular and drug design

AlphaFold 3 demonstrates joint prediction of the structures of complexes containing proteins, nucleic acids, small molecules and other components. Such methods help investigate molecular interactions and choose experimental directions. A predicted structure does not establish a future drug's efficacy or safety.

As computational design advances, feedback from studies and practice becomes more important: what effect is observed, in which groups and under what conditions? For BIOS, this is a possible research application of longitudinal context. We do not replace molecular-design platforms; our interest is the quality of the history used to study a person's response to an intervention.

5. Cell and gene technologies: long-term monitoring

An intervention's outcome may need assessment well beyond the initial treatment course. For example, FDA guidance on long-term follow-up after gene therapy addresses delayed adverse events and the need for long-term observation according to a product's specific risks.

Infrastructure must therefore preserve the connection between baseline state, intervention and subsequent events. Changing clinics or document formats must not break the research history. The value of medical memory is especially clear here. Using BIOS in such studies will require a dedicated protocol, quality controls and collaboration with research centres.

6. Interoperability as a condition for system-wide progress

WHO SMART Guidelines offer an approach to translating guidelines into standardised, reusable digital components. They address a fundamental task: making medical knowledge suitable for consistent use across different systems.

For a laboratory, the concrete outcome is transmitting a value together with its units, method and time. For a clinic, it is preserving meaning during exchange. For a researcher, it is tracing a feature's provenance. BIOS treats these as architectural requirements from the outset; otherwise, later models will depend on relationships whose validity cannot be checked.

What this changes for science and medical practice

The global agenda is expected to focus increasingly on connecting these levels. Scientific value will arise where the path can be traced from observation to hypothesis, from hypothesis to experiment, and back to observation with new knowledge. Each relationship must have clear conditions of applicability.

Within this arrangement, BIOS could connect everyday medical histories with research tasks. To do so, we must make context reproducible: show which data was used, how it changed and why the system reached a particular conclusion. Accumulated histories could then support new studies, while research results return to practice through verifiable tools.

What needs to happen now

This perspective leads to practical decisions. There is no need to wait for a universal health model: much of the necessary work can and should begin with today's tasks.

• Developers: separate component responsibilities. Fact storage, text extraction, observation comparison and prediction each need their own tests. The practical outcome is being able to replace a model and verify that the history and material facts remain intact.
• Clinics: choose a specific scenario and measure the baseline workflow. For example, preparation for a follow-up appointment. Before implementation, record time, completeness of the reconstructed history and critical omissions; afterwards, compare the same measures, including cases where the tool did not help.
• Laboratories: preserve a result's meaning during transfer. A measurement must travel with the necessary method, unit, time and reference-range information. The test is whether histories can still be compared correctly after a new source is connected.
• Research groups: design evaluation across time. Separate patients between training and evaluation, exclude future information, define outcomes in advance and test transferability. Otherwise, a model may reconstruct known information well while being useless for the next decision.
• Investors and development institutions: assess the accumulation of a technology asset. Alongside product revenue, examine reproducibility, integration cost, component reuse and evidence quality. This makes it possible to fund fundamental work through understandable milestones.

For BIOS, this means addressing practical tasks, accumulating verifiable medical memory, assessing every layer's quality and gradually moving to more complex models of dynamics. Commercial work gives research real constraints and criteria of usefulness; research opens possibilities for the next generation of products.

Conclusion. Five principles for the sector's development

Five practical conclusions follow from this approach.

1. Stop measuring technological sovereignty by the number of domestic substitutes. We need to examine which new classes of technology we can create ourselves.
2. Design technological continuity, not isolated products. Data, standards and interfaces must allow individual components to change without dismantling the whole system.
3. Do not separate fundamental development and commercialisation into two worlds. Researchers must understand real-world constraints, and entrepreneurs must work not only with current demand but also with technological hypotheses.
4. Evaluate innovation at every level. Do not present an architectural hypothesis as a proven clinical result, but do not abandon difficult development merely because the market cannot yet articulate it.
5. Build infrastructure so that every new step increases the value and possibilities of earlier work.

This is the principle we chose for BIOS. We deliberately took a more complex path because we do not want another medical service that must be replaced in a few years. We want a system in which data accumulates meaning, individual modules can be recombined into new products, technology becomes more accurate as it develops, and increasing internal complexity gives users a simpler, clearer tool.

The paper's central proposition: infrastructure built today should let us address problems the market has not yet articulated. This capability could become a foundation for technological leadership.

If we learn to connect fundamental science, engineering architecture and business in this way, future conferences will no longer need to discuss only how to replace another foreign technology. We will be able to discuss technologies created here that others are now trying to reproduce.

Sources

1. Sinsky C. et al. Allocation of Physician Time in Ambulatory Practice. Ann Intern Med. 2016;165:753–760. DOI: 10.7326/M16-0961. An observational study of physicians' time allocation in the USA.
2. Narayanswamy G. et al. Towards a General Intelligence and Interface for Wearable Health Data. arXiv:2605.22759v3, 16 July 2026. Preprint. The authors' overview on Google Research, 9 July 2026.
3. Kim E., Foty R., Thakor A. S. et al. Computable longitudinal patient journeys from structured and unstructured EHR data. Nature Medicine, 10.09.2026. DOI: 10.1038/s41591-026-04695-x.
4. Li Z. et al. Fourier Neural Operator for Parametric Partial Differential Equations. ICLR 2021; arXiv:2010.08895v3. Operator learning for problems described by differential equations.
5. WHO SMART Guidelines. Standardised, reusable digital-health components.
6. Vasey B. et al. DECIDE-AI. Nature Medicine 28, 924–933 (2022). DOI: 10.1038/s41591-022-01772-9.
7. Collins G. S. et al. TRIPOD+AI. BMJ 2024;385:e078378. DOI: 10.1136/bmj-2023-078378. Gallifant J. et al. TRIPOD-LLM. Nature Medicine 31, 60–69 (2025).
8. Wu et al. PULSE: modelling past and current states. Nature Computational Science, 2026. DOI: 10.1038/s43588-026-01026-5.
9. Asgari et al. A study of hallucinations and omissions in LLM processing of medical data. npj Digital Medicine, 2025. DOI: 10.1038/s41746-025-01670-7.
10. InfEHR: temporal medical-history graphs and representation learning. Nature Communications, 2025. DOI: 10.1038/s41467-025-63366-6.
11. BIOS original materials.

Sources are current as of 26 September 2026. The evaluation programme describes BIOS's next research stage. Diagnosis and treatment decisions remain with doctors.