PassiveDx: The Body's API PassiveDx, a personal health anomaly detection layer, learns an individual's behavioral and physiological baseline from passive signals such as typing, motion, and sleep, and flags deviations over time. The system, designed as a seven-layer architecture with privacy as its first layer, aims to detect early signs of disease before symptoms become obvious, treating the human body as an API. 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. Every person has a behavioral and physiological baseline. Their: 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. 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. 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. PassiveDx is designed as a seven-layer system. 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: PassiveDx can potentially consume signals from devices people already use. Importantly: The system does not need to store what the person typed. It can operate on derived timing features. Potentially: Only with explicit opt-in. The preferred architecture is: Audio ↓ On-device feature extraction ↓ Acoustic features ↓ Raw audio discarded 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. 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. 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: One unusual event. The same deviation continues for several days. Several independent signals move together. The deviation has sufficient evidence and context to justify human review. 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: Privacy must be engineered, not advertised. 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. 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. 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: It also aligns better with the reality of digital biomarkers: promising signals are not automatically validated diagnostic tests. 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. The most interesting customers are not necessarily consumers. Potential B2B2C customers include: 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. 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: 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 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 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. Interview: Questions: Would patients accept passive monitoring? Which alerts would clinicians actually care about? Which false positives would make the system unusable? Build: iOS / Android + Local Feature Engine + Personal Baseline + Anomaly Model Initial models can be deliberately simple. For example: The goal is not to win a benchmark. The goal is to determine whether the signal exists. 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 Measure: And most importantly: Does PassiveDx detect meaningful change earlier than ordinary care? A serious startup idea needs a failure analysis. If everything becomes an anomaly: Anomaly Anomaly Anomaly Anomaly clinicians will ignore the system. This is the classic alert-fatigue problem. 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. Sensors change. Operating systems change. Keyboard software changes. Wearables change. Hardware generations change. The model must continuously monitor data distribution shifts. One privacy incident could destroy the product. Therefore: Privacy ≠ Feature Privacy = Architecture If the product claims too much too early, the regulatory burden can grow dramatically. Start with: detect → explain → assist not: diagnose → prescribe → autonomously intervene 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 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: You don't check your health. Your health checks in with you. 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