Optimize, don't treat - why informed users need their own data terminal

There is a gap in the German medical ecosystem that gets larger every day. It is not simply between physicians and patients. It sits between what the regulated system is allowed to deliver and what informed users are already doing.

In a short consultation window, even a motivated physician cannot interpret longitudinal biomarker trends, correlate HRV with training load, compare sleep architecture against nutrition context and review supplement logs at high resolution. That is not a criticism of physicians. It is a structural fact.

At the same time, a specific cohort is emerging.

Private data terminal for biomarker context The informed user does not need another isolated app. The missing layer is a coherent terminal.

1. The cohort standard care does not serve

This cohort has many names:

• physique athletes who measure energy balance, recovery and body composition over time
• longevity users influenced by Peter Attia, Bryan Johnson and adjacent communities
• quantified self practitioners with Oura, Whoop, Apple Health, Garmin or private lab panels
• founders, investors and endurance athletes who treat performance as an operating constraint
• biohacking users who read papers, run personal logs and discuss protocols with peers

They are not necessarily ill. They are data-hungry, risk-aware to different degrees and dissatisfied with one-off snapshots.

Standard care was not built for them. It was built for population health, acute symptoms, guideline pathways and reimbursement logic. That work matters. It simply leaves a separate room open: informed users who want a private system for interpretation, comparison and scenario reasoning.

2. The workaround already exists, but it does not scale

The workaround is familiar. Users export CSVs. They keep lab PDFs. They ask Claude or ChatGPT to summarize a blood panel. They compare notes on Reddit. They maintain spreadsheets with sleep, training, glucose and subjective state.

This works until complexity becomes the product.

A spreadsheet can store values. It does not model a trajectory. A chat prompt can explain a single lab marker. It does not maintain a longitudinal context with baselines, context windows and competing explanations.

The user has the data and the motivation. What is missing is a terminal that can hold the whole picture without pretending to be a physician.

3. Why the medical system does not build this terminal

The German system operates within constraints that are rational from its point of view:

• the Medical Device Regulation defines boundaries for diagnosis and treatment software
• the Heilmittelwerbegesetz limits misleading health claims
• GDPR protects sensitive data
• reimbursement logic rewards documented medical services, not private optimization workflows

These constraints prevent dangerous overclaiming. They also make it difficult for the regulated system to build a tool for a user who is not asking for a diagnosis but for an integrated view of personal data.

That is acceptable. The medical system does not have to build every interface.

The question is who builds the layer next to it.

4. International precedents show the category

The category is already visible internationally.

Function Health

Function Health (https://www.functionhealth.com) positions broad biomarker access as an informational service. The core promise is access, continuity and interpretation, not replacement of medical care.

Levels

Levels (https://www.levelshealth.com) focuses on metabolic insight. The positioning is wellness and metabolic education, not diabetes treatment.

Whoop and Oura

Whoop (https://www.whoop.com) and Oura (https://ouraring.com) sit in recovery, sleep and readiness. They are not framed as physician substitutes. They are user-facing signal layers.

The pattern is consistent: the product can exist if its claims, user journey and legal framing remain clear.

5. The user-operated terminal

Table 1 - Standard care vs. user-operated data terminal

| Dimension | Standard care | ARES-category data terminal | |---|---|---| | Data source | Measurements inside medical workflows | User-controlled uploads from many sources | | Interpretation | Population reference ranges | Individual baseline and trajectory | | Decision authority | Clinician-led | User-led, with optional clinician review | | Data sovereignty | Institution-controlled | User exports and deletion by request | | Purpose | Diagnosis and treatment | Information, comparison and simulation | | Regulatory posture | Medical device or clinical software when claims require it | Informational platform when claims stay bounded | | Target group | Patients and standard prevention | Informed power users |

The distinction is simple: one side serves the patient inside a medical workflow. The other gives the user an analytical surface for their own data.

6. What the terminal must do

The useful version is not another dashboard with prettier charts. It needs several primitives:

• unified import for labs, wearable signals, nutrition context, training logs and subjective state
• normalization against individual baseline, not only population range
• signal fusion across sleep, HRV, training load, labs and context
• scenario modeling as calculation, not instruction
• longitudinal projection for biomarkers and performance proxies
• optional physician export as a user-requested brief
• clean deletion, export and provenance for every data point

That is not a doctor. It is a calculator with memory, context and clear boundaries.

7. The hard problem is positioning

The technical field is moving quickly. LLMs can summarize medical text under controlled evaluation, wearable APIs exist, OCR has improved and simulation layers are feasible.

But the legal and product boundary matters more than the demo.

The European Medical Device Regulation (https://eur-lex.europa.eu/eli/reg/2017/745/oj) becomes relevant when software moves into diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease in the regulated sense. The BfArM DiGA directory (https://diga.bfarm.de/de/verzeichnis) shows what the formal digital health app path looks like in Germany.

ARES Bio.OS is intentionally not positioned there. It is a self-measurement and simulation terminal. It presents user data, context, correlations and scenarios. It does not diagnose, prescribe, replace clinical judgment or instruct treatment.

Table 2 - Positioning matrix

| Category | Examples | Typical regulatory frame | |---|---|---| | Medical device | Diagnostic or treatment-guiding software | MDR, clinical evidence, post-market obligations | | Physician software | Practice systems, clinical copilots | Medical, privacy and professional obligations | | Wellness / fitness | Readiness and recovery products | Bounded wellness claims | | Informational self-measurement and simulation | Function Health, Levels, Whoop, Oura, ARES Bio.OS category | Informational platform when claims stay inside the boundary | | Medical literature | Journals, review articles | Publication and copyright rules, not device regulation |

8. What we are building

ARES Bio.OS is a self-measurement and simulation terminal for informed users.

The user brings data. The product organizes, visualizes and models it. The user remains the decision-maker. A physician can be included through an export or review brief when the user wants clinical interpretation.

The mission is not to replace the healthcare system. The mission is to give informed users a coherent interface for the data they already produce.

Optimize, don't treat.

-> bio-os.io (https://bio-os.io)

Disclaimer

ARES Bio.OS is a self-measurement and simulation tool, not a medical device. It does not provide diagnosis, treatment, prescriptions or medical recommendations. This article is educational product positioning, not medical advice. Health questions require a licensed clinician.

Sources

• OECD Health at a Glance 2025 - doctors' consultations and DACH context.
• Nature Medicine - reliability of large language models as medical assistants for the general public.
• Function Health, Levels, Whoop and Oura - public positioning and terms of service.
• European Commission Medical Device Regulation 2017/745 - scope and software boundary.
• Bundesministerium fuer Gesundheit / BfArM - DiGA directory.