Building an AI That Watches Without Asking You to Watch
You don't check your health. Your health checks in with you.
Most health-monitoring systems have the same fundamental assumption:
The patient must participate.
Open the app.
Measure your heart rate.
Take a blood pressure reading.
Answer a questionnaire.
Complete a cognitive test.
Look at your dashboard.
But human health does not behave like an application waiting for a button click.
Disease often begins as a deviation from someone's normal state long before that person recognizes it as a symptom.
What if healthcare could detect those deviations without continuously asking the patient to perform tests?
That is the idea behind PassiveDx.
Not a smartwatch.
Not another health dashboard.
Not an AI doctor.
A personal health anomaly detection layer that quietly learns what "normal" looks like for each person — and looks for meaningful changes over time.
The Core Idea
Every person has a behavioral and physiological baseline.
Their:
- movement patterns
- gait
- typing dynamics
- sleep rhythm
- heart-rate variability
- activity patterns
- respiratory patterns
- micro-movements
- interaction patterns
are not random.
They form a longitudinal signature.
PassiveDx treats this signature as an API.
Human
│
├── Motion
├── Typing
├── Sleep
├── HR/HRV
├── Respiration
└── Activity
│
▼
Personal Baseline
│
▼
Anomaly Detection
│
▼
Clinical Context
│
▼
Healthcare Workflow
The system does not begin with:
"Which disease does this person have?"
It begins with:
"What has changed?"
That distinction is fundamental.
From Diagnosis to Deviation Detection
Traditional clinical systems are usually built around known diseases.
Disease
↓
Symptoms
↓
Test
↓
Diagnosis
PassiveDx reverses the direction:
Continuous Behavior
↓
Personal Baseline
↓
Deviation
↓
Temporal Pattern
↓
Clinical Review
The goal is not to replace diagnosis.
The goal is to detect the signal before the symptom becomes obvious.
That makes PassiveDx closer to an early-warning system than an autonomous doctor.
Why Passive Sensing?
Passive sensing already has scientific foundations.
Smartphone keystroke dynamics, for example, have been studied as potential digital biomarkers for cognitive and neurological states. Research has explored continuously collected typing metadata as a low-burden source of behavioral information.
More recent work also shows that the relationship is not universally predictive: typing features can correlate with some cognitive outcomes while performing differently across populations and domains. That is exactly why PassiveDx should treat these signals as probabilistic evidence, not diagnostic truth.
Wi-Fi Channel State Information (CSI) is another interesting sensing modality.
Research has demonstrated the feasibility of extracting respiratory motion from CSI using commodity hardware, enabling contactless sensing without requiring a dedicated wearable.
The interesting question is therefore not:
"Can one sensor diagnose disease?"
It is:
"Can multiple weak signals become useful when interpreted longitudinally and personalized to one individual?"
That is the architectural bet behind PassiveDx.
The Architecture
PassiveDx is designed as a seven-layer system.
Layer 0 — Consent Fabric
Privacy is not an add-on.
It is the first layer.
Consent
↓
Data Minimization
↓
Local Processing
↓
Selective Synchronization
↓
Auditability
↓
Revocation
Users should be able to decide:
- which sensors are enabled
- what is processed locally
- what metadata can leave the device
- which clinical workflows can receive information
- when consent expires
Layer 1 — Passive Sensors
PassiveDx can potentially consume signals from devices people already use.
Smartphone
- accelerometer
- gyroscope
- motion
- gait-related features
- interaction patterns
Keyboard
- typing speed
- key hold duration
- inter-key intervals
- pause patterns
- correction/backspace behavior
Importantly:
The system does not need to store what the person typed.
It can operate on derived timing features.
Wearables
- heart rate
- HRV
- sleep
- activity
Wi-Fi CSI
Potentially:
- respiration
- movement
- presence
- gait-related patterns
Ambient audio
Only with explicit opt-in.
The preferred architecture is:
Audio
↓
On-device feature extraction
↓
Acoustic features
↓
Raw audio discarded
Layer 2 — Local Feature Engine
Raw data should remain local whenever possible.
Raw Signal
↓
Signal Quality
↓
Feature Extraction
↓
Context Detection
↓
Privacy Filter
↓
Feature Vector
The important principle is:
Do not move the raw signal if the model does not need it.
This dramatically changes the privacy architecture of the product.
Layer 3 — Personal Baseline
This is where PassiveDx becomes fundamentally different from a simple threshold-based monitoring system.
Traditional monitoring might say:
Heart Rate > X
↓
ALERT
PassiveDx asks:
What is normal for this person?
↓
How much has today's behavior changed?
↓
Is the change persistent?
↓
Does another independent modality support it?
For example:
Day 1–14
Personal Calibration
↓
Baseline Model
↓
Day 15+
↓
Deviation Detection
The baseline should also be adaptive.
People change.
Travel changes sleep.
Exercise changes heart rate.
Stress changes typing.
Illness changes activity.
Therefore:
Personal baseline ≠ static threshold.
Layer 4 — Multimodal Anomaly Fusion
One abnormal signal should rarely trigger a clinical workflow.
Instead:
Motion anomaly ─────┐
│
Typing anomaly ─────┤
├──► Temporal Fusion
Sleep anomaly ──────┤
│
HRV anomaly ────────┘
│
▼
Confidence Score
A useful conceptual model is:
Anomaly =
f(
magnitude,
persistence,
modality_count,
signal_quality,
context,
baseline_distance
)
This creates an important distinction:
Weak anomaly
One unusual event.
Persistent anomaly
The same deviation continues for several days.
Multimodal anomaly
Several independent signals move together.
Clinically relevant anomaly
The deviation has sufficient evidence and context to justify human review.
Layer 5 — Federated Intelligence
The global model should learn from populations.
The personal model should remain personal.
GLOBAL MODEL
▲
│
Secure Aggregation
│
┌──────────┼──────────┐
│ │ │
Device A Device B Device C
│ │ │
Local Model Local Model Local Model
Instead of centralizing raw health data:
Raw Data
X
we aim for:
Local Training
↓
Model Updates
↓
Secure Aggregation
↓
Global Model
Combined with differential privacy and strict data minimization, this creates a much stronger privacy posture than a centralized health-data warehouse.
But federated learning is not magic privacy.
It still requires:
- secure aggregation
- threat modeling
- update protection
- membership-inference analysis
- poisoning defenses
- access control
- auditability
Privacy must be engineered, not advertised.
Layer 6 — Clinical Orchestration
This is where PassiveDx stops being a consumer health app.
The output should not simply be:
"Your health score is 82."
Instead:
Anomaly
↓
Confidence
↓
Context
↓
Clinical Policy
↓
Action
Possible actions:
LOW
↓
Continue observation
MEDIUM
↓
Request non-urgent check-in
HIGH
↓
Clinical review
CRITICAL
↓
Emergency workflow
The crucial design principle:
The AI generates evidence. The clinical system decides what to do with it.
Any emergency automation would require especially careful validation, consent, failure handling, and regulatory analysis.
Layer 7 — Healthcare API
The final layer connects PassiveDx to healthcare infrastructure.
Conceptually:
PassiveDx
↓
FHIR
↓
EHR
↓
Clinician Dashboard
↓
Clinical Workflow
The system should not attempt to replace the EHR.
It should become an additional longitudinal signal layer.
Think of it as:
An API between everyday life and clinical care.
The Most Important Design Principle
PassiveDx should never claim:
"The AI diagnosed Parkinson's."
A safer and more scientifically defensible statement is:
"The system detected a persistent deviation in motor behavior relative to the individual's historical baseline."
That difference is enormous.
It changes:
- product positioning
- clinical validation
- regulatory strategy
- liability
- UX
- model design
It also aligns better with the reality of digital biomarkers: promising signals are not automatically validated diagnostic tests.
Regulatory Reality
This is where many AI-healthcare startups become overconfident.
If software analyzes signals for a medical purpose and produces diagnostic, risk, or time-critical outputs, regulatory obligations may apply.
The FDA's 2026 Clinical Decision Support guidance explicitly distinguishes non-device CDS from software functions that analyze medical signals or produce specific diagnostic, preventive, treatment, or time-critical outputs.
Therefore, PassiveDx should initially position itself around:
anomaly detection + clinician decision support
rather than:
autonomous diagnosis.
The exact regulatory pathway would depend on the intended use, claims, inputs, outputs, population, and implementation.
This is not merely legal wording.
It should influence the architecture from day one.
Business Model
The most interesting customers are not necessarily consumers.
Potential B2B2C customers include:
- health systems
- chronic-care providers
- health insurers
- Medicare Advantage organizations
- employers
- research organizations
The revenue model could be:
Provider SaaS
↓
Per-member-per-month
↓
Enterprise contracts
↓
API licensing
↓
Population-health analytics
A hypothetical model:
$5 PMPM
1,000 users
= $5,000/month
100,000 users
= $500,000/month
1,000,000 users
= $5M/month
These are illustrative assumptions, not forecasts.
Why Medicare Advantage Is Interesting
Medicare Advantage uses risk adjustment models that incorporate documented diagnoses and other beneficiary information.
For CY2026, CMS completed the phase-in of the 2024 CMS-HCC model for non-PACE organizations, using 100% of that model for risk scores.
That creates an interesting commercial environment for technologies that can support:
- earlier clinical attention
- longitudinal monitoring
- care management
- documentation workflows
- identification of patients needing evaluation
But there is an important boundary:
PassiveDx should not be marketed as a machine for manufacturing HCC codes or increasing CMS payments.
The economic value proposition should be:
Better detection
↓
Better clinical attention
↓
Better care management
↓
Potentially fewer avoidable events
↓
Better population health economics
Risk adjustment is one component of the business case, not the product itself.
The Moat
The moat is not the gyroscope.
It is not the keyboard.
It is not Wi-Fi CSI.
It is not the autoencoder.
All of these technologies can be reproduced.
The moat is:
Longitudinal Data
+
Personal Baselines
+
Multimodal Fusion
+
Clinical Validation
+
Privacy Infrastructure
+
Healthcare Integration
The longer the system observes a person, the richer the baseline becomes.
The longer it operates across validated populations, the better the population model becomes.
That creates a compounding loop:
More longitudinal data
↓
Better personalized models
↓
Better anomaly detection
↓
Better clinical validation
↓
More trust
↓
More adoption
↓
More longitudinal data
That is a much stronger moat than simply owning an AI model.
The MVP
The biggest mistake would be trying to build every modality simultaneously.
A realistic MVP should start with three signals:
Smartphone Motion
+
Keyboard Dynamics
+
Wearable HR/Activity
Then:
Personal Baseline
↓
Temporal Anomaly Detection
↓
Clinician Dashboard
Wi-Fi CSI can become an experimental fourth modality.
Ambient audio should remain optional and privacy-sensitive.
90-Day Roadmap
Phase 1 — Weeks 1–2
Validation
Interview:
- physicians
- nurses
- chronic-care teams
- patients
- health-plan stakeholders
Questions:
Would patients accept passive monitoring?
Which alerts would clinicians actually care about?
Which false positives would make the system unusable?
Phase 2 — Weeks 3–5
Prototype
Build:
iOS / Android
+
Local Feature Engine
+
Personal Baseline
+
Anomaly Model
Initial models can be deliberately simple.
For example:
- Isolation Forest
- Autoencoder
- robust z-score
- Bayesian change-point detection
The goal is not to win a benchmark.
The goal is to determine whether the signal exists.
Phase 3 — Weeks 6–9
Pilot
Start small.
50–100 participants
↓
8–12 weeks
↓
Baseline
↓
Anomaly events
↓
Clinical adjudication
Do not jump immediately to 1,000 Medicare members.
First prove:
signal → reproducibility → clinical relevance
Phase 4 — Weeks 10–12
Clinical Validation
Measure:
- sensitivity
- specificity
- false-positive rate
- alert burden
- calibration
- AUROC / AUPRC where appropriate
- time-to-detection
- patient adherence
- clinician acceptance
And most importantly:
Does PassiveDx detect meaningful change earlier than ordinary care?
What Could Kill PassiveDx?
A serious startup idea needs a failure analysis.
1. False Positives
If everything becomes an anomaly:
Anomaly
Anomaly
Anomaly
Anomaly
clinicians will ignore the system.
This is the classic alert-fatigue problem.
2. Confounding
A person travels.
Changes phones.
Starts exercising.
Changes medication.
Gets a new job.
Changes sleep schedule.
The model may interpret normal life as disease.
Therefore context modeling is mandatory.
3. Data Drift
Sensors change.
Operating systems change.
Keyboard software changes.
Wearables change.
Hardware generations change.
The model must continuously monitor data distribution shifts.
4. Privacy Failure
One privacy incident could destroy the product.
Therefore:
Privacy
≠ Feature
Privacy
= Architecture
5. Regulatory Overreach
If the product claims too much too early, the regulatory burden can grow dramatically.
Start with:
detect → explain → assist
not:
diagnose → prescribe → autonomously intervene
The Bigger Vision
PassiveDx is ultimately not about smartphones.
It is about changing the interface between humans and healthcare.
Today:
Patient
↓
Symptom
↓
Appointment
↓
Test
↓
Diagnosis
Tomorrow:
Everyday Life
↓
Passive Signals
↓
Personal Health Baseline
↓
Deviation
↓
Clinical Intelligence
↓
Human Intervention
The healthcare system would no longer need to wait until the patient becomes sufficiently concerned to ask for help.
It could detect meaningful changes earlier.
Not because AI understands the human body perfectly.
But because AI can continuously observe change over time.
The Body's API
The deepest idea behind PassiveDx can be expressed in one sentence:
Your body already produces a continuous stream of health signals. We just haven't built the API yet.
The smartphone is not the product.
The smartwatch is not the product.
The Wi-Fi router is not the product.
The AI model is not even the product.
The product is the intelligence layer connecting everyday human behavior to healthcare.
THE HUMAN
│
┌────────┴────────┐
│ │
Signals Context
│ │
└────────┬────────┘
▼
PERSONAL HEALTH API
│
▼
ANOMALY DETECTION
│
▼
CLINICAL INTELLIGENCE
│
▼
HUMAN DECISION
And that leads to the real vision:
PassiveDx
The Body's API
You don't check your health.
Your health checks in with you.
Final Thought
The future of healthcare may not be another device that asks us to measure ourselves.
It may be an invisible intelligence layer that learns our baseline, understands our context, detects meaningful deviations, protects our raw data, and knows when to stay silent.
Because the best health alert may not be the one that talks the most.
It may be the one that knows exactly when it is worth interrupting you.
created by Seyed Alireza Alhosseini Almodarresieh
Top comments (0)