{"slug": "passivedx-the-body-s-api", "title": "PassiveDx: The Body's API", "summary": "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.", "body_md": "Building an AI That Watches Without Asking You to Watch\n\nYou don't check your health. Your health checks in with you.\n\nMost health-monitoring systems have the same fundamental assumption:\n\n**The patient must participate.**\n\nOpen the app.\n\nMeasure your heart rate.\n\nTake a blood pressure reading.\n\nAnswer a questionnaire.\n\nComplete a cognitive test.\n\nLook at your dashboard.\n\nBut human health does not behave like an application waiting for a button click.\n\nDisease often begins as a deviation from someone's normal state long before that person recognizes it as a symptom.\n\nWhat if healthcare could detect those deviations without continuously asking the patient to perform tests?\n\nThat is the idea behind **PassiveDx**.\n\nNot a smartwatch.\n\nNot another health dashboard.\n\nNot an AI doctor.\n\n**A personal health anomaly detection layer that quietly learns what \"normal\" looks like for each person — and looks for meaningful changes over time.**\n\nEvery person has a behavioral and physiological baseline.\n\nTheir:\n\nare not random.\n\nThey form a longitudinal signature.\n\nPassiveDx treats this signature as an API.\n\n```\nHuman\n  │\n  ├── Motion\n  ├── Typing\n  ├── Sleep\n  ├── HR/HRV\n  ├── Respiration\n  └── Activity\n          │\n          ▼\n   Personal Baseline\n          │\n          ▼\n    Anomaly Detection\n          │\n          ▼\n   Clinical Context\n          │\n          ▼\n   Healthcare Workflow\n```\n\nThe system does not begin with:\n\n\"Which disease does this person have?\"\n\nIt begins with:\n\n\"What has changed?\"\n\nThat distinction is fundamental.\n\nTraditional clinical systems are usually built around known diseases.\n\n```\nDisease\n   ↓\nSymptoms\n   ↓\nTest\n   ↓\nDiagnosis\n```\n\nPassiveDx reverses the direction:\n\n```\nContinuous Behavior\n        ↓\nPersonal Baseline\n        ↓\nDeviation\n        ↓\nTemporal Pattern\n        ↓\nClinical Review\n```\n\nThe goal is not to replace diagnosis.\n\nThe goal is to detect **the signal before the symptom becomes obvious**.\n\nThat makes PassiveDx closer to an early-warning system than an autonomous doctor.\n\nPassive sensing already has scientific foundations.\n\nSmartphone 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.\n\nMore 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.\n\nWi-Fi Channel State Information (CSI) is another interesting sensing modality.\n\nResearch has demonstrated the feasibility of extracting respiratory motion from CSI using commodity hardware, enabling contactless sensing without requiring a dedicated wearable.\n\nThe interesting question is therefore not:\n\n\"Can one sensor diagnose disease?\"\n\nIt is:\n\n\"Can multiple weak signals become useful when interpreted longitudinally and personalized to one individual?\"\n\nThat is the architectural bet behind PassiveDx.\n\nPassiveDx is designed as a seven-layer system.\n\nPrivacy is not an add-on.\n\nIt is the first layer.\n\n```\nConsent\n  ↓\nData Minimization\n  ↓\nLocal Processing\n  ↓\nSelective Synchronization\n  ↓\nAuditability\n  ↓\nRevocation\n```\n\nUsers should be able to decide:\n\nPassiveDx can potentially consume signals from devices people already use.\n\nImportantly:\n\n**The system does not need to store what the person typed.**\n\nIt can operate on derived timing features.\n\nPotentially:\n\nOnly with explicit opt-in.\n\nThe preferred architecture is:\n\n```\nAudio\n  ↓\nOn-device feature extraction\n  ↓\nAcoustic features\n  ↓\nRaw audio discarded\n```\n\nRaw data should remain local whenever possible.\n\n```\nRaw Signal\n    ↓\nSignal Quality\n    ↓\nFeature Extraction\n    ↓\nContext Detection\n    ↓\nPrivacy Filter\n    ↓\nFeature Vector\n```\n\nThe important principle is:\n\nDo not move the raw signal if the model does not need it.\n\nThis dramatically changes the privacy architecture of the product.\n\nThis is where PassiveDx becomes fundamentally different from a simple threshold-based monitoring system.\n\nTraditional monitoring might say:\n\n```\nHeart Rate > X\n      ↓\nALERT\n```\n\nPassiveDx asks:\n\n```\nWhat is normal for this person?\n             ↓\nHow much has today's behavior changed?\n             ↓\nIs the change persistent?\n             ↓\nDoes another independent modality support it?\n```\n\nFor example:\n\n```\nDay 1–14\nPersonal Calibration\n        ↓\nBaseline Model\n        ↓\nDay 15+\n        ↓\nDeviation Detection\n```\n\nThe baseline should also be adaptive.\n\nPeople change.\n\nTravel changes sleep.\n\nExercise changes heart rate.\n\nStress changes typing.\n\nIllness changes activity.\n\nTherefore:\n\n**Personal baseline ≠ static threshold.**\n\nOne abnormal signal should rarely trigger a clinical workflow.\n\nInstead:\n\n```\nMotion anomaly ─────┐\n                    │\nTyping anomaly ─────┤\n                    ├──► Temporal Fusion\nSleep anomaly ──────┤\n                    │\nHRV anomaly ────────┘\n                           │\n                           ▼\n                    Confidence Score\n```\n\nA useful conceptual model is:\n\n```\nAnomaly =\n    f(\n       magnitude,\n       persistence,\n       modality_count,\n       signal_quality,\n       context,\n       baseline_distance\n     )\n```\n\nThis creates an important distinction:\n\nOne unusual event.\n\nThe same deviation continues for several days.\n\nSeveral independent signals move together.\n\nThe deviation has sufficient evidence and context to justify human review.\n\nThe global model should learn from populations.\n\nThe personal model should remain personal.\n\n```\n              GLOBAL MODEL\n                   ▲\n                   │\n        Secure Aggregation\n                   │\n        ┌──────────┼──────────┐\n        │          │          │\n     Device A   Device B   Device C\n        │          │          │\n   Local Model Local Model Local Model\n```\n\nInstead of centralizing raw health data:\n\n```\nRaw Data\n   X\n```\n\nwe aim for:\n\n```\nLocal Training\n      ↓\nModel Updates\n      ↓\nSecure Aggregation\n      ↓\nGlobal Model\n```\n\nCombined with differential privacy and strict data minimization, this creates a much stronger privacy posture than a centralized health-data warehouse.\n\nBut federated learning is not magic privacy.\n\nIt still requires:\n\nPrivacy must be engineered, not advertised.\n\nThis is where PassiveDx stops being a consumer health app.\n\nThe output should not simply be:\n\n\"Your health score is 82.\"\n\nInstead:\n\n```\nAnomaly\n   ↓\nConfidence\n   ↓\nContext\n   ↓\nClinical Policy\n   ↓\nAction\n```\n\nPossible actions:\n\n```\nLOW\n↓\nContinue observation\n\nMEDIUM\n↓\nRequest non-urgent check-in\n\nHIGH\n↓\nClinical review\n\nCRITICAL\n↓\nEmergency workflow\n```\n\nThe crucial design principle:\n\nThe AI generates evidence. The clinical system decides what to do with it.\n\nAny emergency automation would require especially careful validation, consent, failure handling, and regulatory analysis.\n\nThe final layer connects PassiveDx to healthcare infrastructure.\n\nConceptually:\n\n```\nPassiveDx\n    ↓\nFHIR\n    ↓\nEHR\n    ↓\nClinician Dashboard\n    ↓\nClinical Workflow\n```\n\nThe system should not attempt to replace the EHR.\n\nIt should become an additional longitudinal signal layer.\n\nThink of it as:\n\nAn API between everyday life and clinical care.\n\nPassiveDx should never claim:\n\n\"The AI diagnosed Parkinson's.\"\n\nA safer and more scientifically defensible statement is:\n\n\"The system detected a persistent deviation in motor behavior relative to the individual's historical baseline.\"\n\nThat difference is enormous.\n\nIt changes:\n\nIt also aligns better with the reality of digital biomarkers: promising signals are not automatically validated diagnostic tests.\n\nThis is where many AI-healthcare startups become overconfident.\n\nIf software analyzes signals for a medical purpose and produces diagnostic, risk, or time-critical outputs, regulatory obligations may apply.\n\nThe 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.\n\nTherefore, PassiveDx should initially position itself around:\n\n**anomaly detection + clinician decision support**\n\nrather than:\n\n**autonomous diagnosis.**\n\nThe exact regulatory pathway would depend on the intended use, claims, inputs, outputs, population, and implementation.\n\nThis is not merely legal wording.\n\nIt should influence the architecture from day one.\n\nThe most interesting customers are not necessarily consumers.\n\nPotential B2B2C customers include:\n\nThe revenue model could be:\n\n```\nProvider SaaS\n     ↓\nPer-member-per-month\n     ↓\nEnterprise contracts\n     ↓\nAPI licensing\n     ↓\nPopulation-health analytics\n```\n\nA hypothetical model:\n\n```\n$5 PMPM\n\n1,000 users\n= $5,000/month\n\n100,000 users\n= $500,000/month\n\n1,000,000 users\n= $5M/month\n```\n\nThese are illustrative assumptions, not forecasts.\n\nMedicare Advantage uses risk adjustment models that incorporate documented diagnoses and other beneficiary information.\n\nFor CY2026, CMS completed the phase-in of the 2024 CMS-HCC model for non-PACE organizations, using 100% of that model for risk scores.\n\nThat creates an interesting commercial environment for technologies that can support:\n\nBut there is an important boundary:\n\n**PassiveDx should not be marketed as a machine for manufacturing HCC codes or increasing CMS payments.**\n\nThe economic value proposition should be:\n\n```\nBetter detection\n      ↓\nBetter clinical attention\n      ↓\nBetter care management\n      ↓\nPotentially fewer avoidable events\n      ↓\nBetter population health economics\n```\n\nRisk adjustment is one component of the business case, not the product itself.\n\nThe moat is not the gyroscope.\n\nIt is not the keyboard.\n\nIt is not Wi-Fi CSI.\n\nIt is not the autoencoder.\n\nAll of these technologies can be reproduced.\n\nThe moat is:\n\n```\nLongitudinal Data\n       +\nPersonal Baselines\n       +\nMultimodal Fusion\n       +\nClinical Validation\n       +\nPrivacy Infrastructure\n       +\nHealthcare Integration\n```\n\nThe longer the system observes a person, the richer the baseline becomes.\n\nThe longer it operates across validated populations, the better the population model becomes.\n\nThat creates a compounding loop:\n\n```\nMore longitudinal data\n        ↓\nBetter personalized models\n        ↓\nBetter anomaly detection\n        ↓\nBetter clinical validation\n        ↓\nMore trust\n        ↓\nMore adoption\n        ↓\nMore longitudinal data\n```\n\nThat is a much stronger moat than simply owning an AI model.\n\nThe biggest mistake would be trying to build every modality simultaneously.\n\nA realistic MVP should start with three signals:\n\n```\nSmartphone Motion\n       +\nKeyboard Dynamics\n       +\nWearable HR/Activity\n```\n\nThen:\n\n```\nPersonal Baseline\n       ↓\nTemporal Anomaly Detection\n       ↓\nClinician Dashboard\n```\n\nWi-Fi CSI can become an experimental fourth modality.\n\nAmbient audio should remain optional and privacy-sensitive.\n\nInterview:\n\nQuestions:\n\nWould patients accept passive monitoring?\n\nWhich alerts would clinicians actually care about?\n\nWhich false positives would make the system unusable?\n\nBuild:\n\n```\niOS / Android\n      +\nLocal Feature Engine\n      +\nPersonal Baseline\n      +\nAnomaly Model\n```\n\nInitial models can be deliberately simple.\n\nFor example:\n\nThe goal is not to win a benchmark.\n\nThe goal is to determine whether the signal exists.\n\nStart small.\n\n```\n50–100 participants\n       ↓\n8–12 weeks\n       ↓\nBaseline\n       ↓\nAnomaly events\n       ↓\nClinical adjudication\n```\n\nDo not jump immediately to 1,000 Medicare members.\n\nFirst prove:\n\n**signal → reproducibility → clinical relevance**\n\nMeasure:\n\nAnd most importantly:\n\nDoes PassiveDx detect meaningful change earlier than ordinary care?\n\nA serious startup idea needs a failure analysis.\n\nIf everything becomes an anomaly:\n\n```\nAnomaly\nAnomaly\nAnomaly\nAnomaly\n```\n\nclinicians will ignore the system.\n\nThis is the classic alert-fatigue problem.\n\nA person travels.\n\nChanges phones.\n\nStarts exercising.\n\nChanges medication.\n\nGets a new job.\n\nChanges sleep schedule.\n\nThe model may interpret normal life as disease.\n\nTherefore context modeling is mandatory.\n\nSensors change.\n\nOperating systems change.\n\nKeyboard software changes.\n\nWearables change.\n\nHardware generations change.\n\nThe model must continuously monitor data distribution shifts.\n\nOne privacy incident could destroy the product.\n\nTherefore:\n\n```\nPrivacy\n≠ Feature\n\nPrivacy\n= Architecture\n```\n\nIf the product claims too much too early, the regulatory burden can grow dramatically.\n\nStart with:\n\n**detect → explain → assist**\n\nnot:\n\n**diagnose → prescribe → autonomously intervene**\n\nPassiveDx is ultimately not about smartphones.\n\nIt is about changing the interface between humans and healthcare.\n\nToday:\n\n```\nPatient\n   ↓\nSymptom\n   ↓\nAppointment\n   ↓\nTest\n   ↓\nDiagnosis\n```\n\nTomorrow:\n\n```\nEveryday Life\n      ↓\nPassive Signals\n      ↓\nPersonal Health Baseline\n      ↓\nDeviation\n      ↓\nClinical Intelligence\n      ↓\nHuman Intervention\n```\n\nThe healthcare system would no longer need to wait until the patient becomes sufficiently concerned to ask for help.\n\nIt could detect meaningful changes earlier.\n\nNot because AI understands the human body perfectly.\n\nBut because AI can continuously observe **change over time**.\n\nThe deepest idea behind PassiveDx can be expressed in one sentence:\n\nYour body already produces a continuous stream of health signals. We just haven't built the API yet.\n\nThe smartphone is not the product.\n\nThe smartwatch is not the product.\n\nThe Wi-Fi router is not the product.\n\nThe AI model is not even the product.\n\nThe product is the **intelligence layer connecting everyday human behavior to healthcare.**\n\n```\n             THE HUMAN\n                 │\n        ┌────────┴────────┐\n        │                 │\n     Signals           Context\n        │                 │\n        └────────┬────────┘\n                 ▼\n       PERSONAL HEALTH API\n                 │\n                 ▼\n        ANOMALY DETECTION\n                 │\n                 ▼\n       CLINICAL INTELLIGENCE\n                 │\n                 ▼\n          HUMAN DECISION\n```\n\nAnd that leads to the real vision:\n\nYou don't check your health.\n\nYour health checks in with you.\n\nThe future of healthcare may not be another device that asks us to measure ourselves.\n\nIt 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.\n\nBecause the best health alert may not be the one that talks the most.\n\n**It may be the one that knows exactly when it is worth interrupting you.**\n\ncreated by Seyed Alireza Alhosseini Almodarresieh", "url": "https://wpnews.pro/news/passivedx-the-body-s-api", "canonical_source": "https://dev.to/alirezaai/passivedx-the-bodys-api-4f3c", "published_at": "2026-08-05 04:39:03+00:00", "updated_at": "2026-08-05 04:43:32.361692+00:00", "lang": "en", "topics": ["artificial-intelligence", "machine-learning"], "entities": ["PassiveDx"], "alternates": {"html": "https://wpnews.pro/news/passivedx-the-body-s-api", "markdown": "https://wpnews.pro/news/passivedx-the-body-s-api.md", "text": "https://wpnews.pro/news/passivedx-the-body-s-api.txt", "jsonld": "https://wpnews.pro/news/passivedx-the-body-s-api.jsonld"}}