idea-014 · feasibility deck
Every slide states a condition that would have to be true, then reports where it stands using the candidate file's own claim and its own confidence tag. A deck never upgrades a tag, invents a number, or recommends anything, and there is no ask slide.
The chair: engineering — the people who would have to build the device and app, produce bench and clinical evidence, and submit a 510(k) under whichever regulatory route governs.
How to read this: every slide is a condition, not a conclusion. A bracketed claim reference points into knowledge-base/candidates/idea-014.md — the number is the claim's position in its ## Claims list, the tag is copied from it and never adjusted here. A [no claim] marker means nothing in the file speaks to this. See docs/deck-spec.md.
First build. No prototype exists for this device — the device_class frontmatter field itself names two live, mutually exclusive regulatory routes and states plainly that "neither route has been confirmed by a classification lookup." Every slide below is read against that fact.
Would have to be true: A handheld, Bluetooth-connected electronic peak-flow meter and/or spirometer, paired with a smartphone app, would have to log daily peak expiratory flow and/or FEV1 readings alongside a structured symptom-and-medication-adherence questionnaire, transmit the combined record to the prescribing clinician's RPM workflow, and flag readings that cross a patient-specific asthma-action-plan threshold — for children and adolescents ages 5-17 with physician-diagnosed persistent asthma, and explicitly not for acute respiratory distress or emergency use.
Where it stands: This is the candidate's own mechanism and intended_use frontmatter, restated as a spec rather than a claim — no claim independently verifies that this candidate's own (unbuilt) hardware meets it, since no prototype exists to test. What is checkable is that the measurement half of this spec is not unprecedented: an app-based portable home spirometer (VitalFlo, a different product) correlated highly with a clinic-grade spirometer (nSpire KoKo sx1000) in 48 adolescents with persistent asthma across 240 measurements, with no statistically significant difference in mean FEV1 (P=.87) [claim 24: verified]. Formalized in this deck's write-back as the specific gap that analog does not close: this candidate's own hardware achieves comparable accuracy when tested in its own 5-17 target age range, not only the adolescent subset VitalFlo studied [claim 29: unverified].
What would settle it: A written device requirements specification with quantities (flow range, FEV1 accuracy tolerance, sampling rate, Bluetooth range/reliability) — none of which exist in this file yet; a first physical prototype tested against a clinic-grade comparator across the full 5-17 age range.
If it's false: Every downstream slide is moot — there is no device to classify, bench-test, or manufacture.
Would have to be true: Beyond raw measurement accuracy, the threshold-based alerting logic — flagging readings that cross a patient-specific asthma-action-plan threshold for clinician review between visits — would have to reliably distinguish clinically meaningful deteriorations from noise, with an acceptable false-alarm and missed-exacerbation rate.
Where it stands: No claim in the file addresses the alerting algorithm at all. Claim 24's verified accuracy result [claim 24: verified] is about instrument-to-instrument agreement on a single reading, not about whether a sequence of readings correctly triggers or withholds a clinical alert over time. Formalized in this deck's write-back rather than left silently assumed: the threshold-based alerting algorithm achieves clinically acceptable sensitivity and specificity for detecting exacerbation risk in pediatric persistent-asthma patients [claim 30: unverified].
What would settle it: A retrospective or prospective validation of the alerting logic against clinician-adjudicated exacerbation events — a study design distinct from, and not yet scoped anywhere in the file the way, claim 24's accuracy comparison was.
If it's false: The device produces accurate readings that either miss clinically important deteriorations or generate enough false alarms that clinicians and families stop trusting them — undermining both the desirability deck's "what would make them believe it" slide and the clinical rationale for RPM billing in the first place.
Would have to be true: Whichever 510(k) route actually governs would have to be known, because it sets the entire build and evidence spec — whether the symptom/medication- questionnaire software has to be validated as part of one combined-function submission, or can be handled as separable accessory software alongside a bare-hardware submission.
Where it stands: Two routes remain open, and the file's own device_class field states neither has been confirmed by a classification lookup. Route one: Class II, 510(k), 21 CFR 868.1840 (diagnostic spirometer), product code BZG, following the "Asthma Monitor AM3 G+" (K183479) predicate — verified real: Class II, 510(k), decided 2019-10-03, substantially equivalent, labeling confirmed verbatim as "electronic measurement device to monitor the lung function," with a stored symptom/medications questionnaire function (AMOS software, up to 400 question sets, 20 questions each), for home and clinical use, children 5+ [claim 1: verified]. Route two: Class II, 510(k), 21 CFR 868.1860 (peak flow meter), product code BZH, treating the hardware and tracking app as functionally separate — the classification itself is verified real and Class II [claim 3: verified], but the specific bare-hardware predicate (K200832 "Safey Peak Flow Meter") remains unconfirmed on the details that matter for this route: its OTC-vs-Rx status, its "children over 5" age claim, and whether it even cites K181666 as its own predicate — FDA's PDF summary returns HTTP 401 [claim 2: unconfirmed]. If neither predicate route fits cleanly, the file names no De Novo fallback explicitly, unlike some other candidates in this repo.
What would settle it: An openFDA classification lookup plus a direct read of the K183479 510(k) summary PDF to confirm which predicate route the Verifier's next pass should treat as governing — named explicitly as the Scores table's own gap for this factor.
If it's false: If the combined-function (BZG) route governs, the symptom/medication questionnaire has to be validated as part of the same 510(k) submission as the hardware — materially more evidence burden than treating the app as separable accessory software under the bare-hardware (BZH) route.
Would have to be true: The app's data pathway from the home device into the prescribing clinician's actual RPM workflow — however that workflow is implemented at a given practice — would have to be built, and would have to meet whatever cybersecurity and software- documentation requirements apply to the regulatory class Slide 3 resolves.
Where it stands: No claim in the file addresses software level, cybersecurity, or EHR/RPM-platform interoperability at all — the mechanism description states that the device "transmits the combined record to the prescribing clinician's remote-physiologic-monitoring (RPM) workflow" but no claim specifies how, or what documentation that transmission would require under FDA's software guidance. Formalized in this deck's write-back: the app's data pathway into the prescribing clinician's RPM/EHR workflow meets FDA's applicable cybersecurity and software-documentation requirements for this device's regulatory class [claim 31: unverified].
What would settle it: A software-level determination (per FDA's software-in-a-medical- device guidance) once Slide 3's regulatory route is known, and a cybersecurity risk assessment against the specific data-transmission architecture — neither scoped in the file yet.
If it's false: A device that measures and alerts correctly but cannot deliver that data into a form the clinician's actual RPM billing/documentation workflow accepts produces no billable RPM record regardless of what the viability deck's reimbursement slides establish about rates.
Would have to be true: A bench-and-validation program would have to demonstrate accuracy across the full 5-17 target age range and acceptable alerting performance before any clinical deployment — and no agent in this repo is positioned to greenlight an animal or human study regardless.
Where it stands: No prototype-specific bench or validation evidence exists. The nearest analog, VitalFlo's validation study, demonstrates that the general approach (app-based home spirometry vs. clinic-grade comparator) can work in adolescents [claim 24: verified], but says nothing about this candidate's own hardware [claim 29: unverified] or its alerting algorithm [claim 30: unverified] — both formalized as open conditions by this deck's write-back rather than assumed to inherit VitalFlo's result.
What would settle it: A device-specific validation study replicating VitalFlo's design (paired measurements against a clinic-grade comparator) across the full 5-17 age range, plus the alerting-algorithm validation named in Slide 2 — neither scoped in the file yet.
If it's false: There is no bench basis to propose further evaluation, and per the trust-tier rule this repo enforces structurally, no agent here would propose one regardless of what a bench study showed.
Would have to be true: The device would have to be manufacturable, connectable, and usable correctly at home — including by the youngest end of the intended-use range — without a clinician present after initial training.
Where it stands: No claim addresses manufacturing, unit cost, or shelf life at all [no claim]. The human-factors question is sharper for this candidate than for an adult product: the intended use spans ages 5-17, and no claim addresses whether a child at the young end of that range can reliably perform a spirometry/peak-flow maneuver at home, coached only by a parent, well enough to produce usable RPM data — a question distinct from claim 24's adolescent-only validation cohort and from claim 14's adherence question (willingness to attempt the maneuver, not technique quality once attempted) [claim 14: unconfirmed] — see the desirability deck's Slide 2 and load-bearing condition, referenced rather than duplicated here.
What would settle it: A formative human-factors study in a home-like setting, across the full 5-17 age range, per whatever human-factors guidance applies to the device class Slide 3 resolves; a manufacturability/DFM review against a target unit cost, which no claim currently supplies.
If it's false: If usable maneuver technique cannot be reliably achieved at the young end of the age range, the intended use would need to narrow (e.g., a higher minimum age), which changes the population the desirability and viability decks' TAM slides are sized against.
Would have to be true: No live, enforceable patent would have to cover the specific combination of continuous RPM billing plus an action-plan-threshold alerting algorithm on connected peak-flow/spirometry hardware — or, if one does, a design workaround would have to exist that does not compromise the mechanism in Slides 1-2.
Where it stands: Genuinely unexamined, not clear. No patent or FTO search was performed at all: predicate hardware (electronic peak-flow meters, digital spirometers) has existed since at least the mid-2010s, but FTO for this specific hardware-plus-billing-plus-alerting combination "is entirely unexamined," and the connector requires a specific patent number to check, with none named — EPO_OPS_KEY/EPO_OPS_SECRET are also unset in this environment regardless [claim 12: unconfirmed]. An absence of a search result here is not freedom to operate, and must not be read as an open field.
What would settle it: A PATENTSVIEW-backed patent-landscape search for claims covering connected peak-flow/spirometry devices combined with RPM-eligible data transmission and asthma-action-plan-threshold alerting logic — named explicitly as the Scores table's own gap for this factor.
If it's false: If a live patent's claims read broadly enough to cover the alerting-plus-RPM-billing combination described in Slide 2, the alerting mechanism would need to design around it, or this candidate does not have a buildable, unencumbered version of its own core differentiator (the billing/indication-scope lever named in the viability deck's Slide 5).
Every condition above with nothing verified behind it — the [no claim] markers, plus the unverified claims this deck itself put on record. Read this slide first.
Structural note: the file's verified claims in this deck's territory (claims 1, 3, 21, 24) confirm that real predicates and a real accuracy analog exist — none of them confirm that this candidate's own hardware, alerting logic, or software architecture actually works, because none of it has been built yet.
If only one thing from this chair could be checked: which 510(k) route actually governs this device — the combined-function route via 21 CFR 868.1840/BZG (K183479 predicate) [claim 1: verified] or the bare-hardware-plus-accessory-software route via 21 CFR 868.1860/BZH (K200832 or K230423 predicates) [claim 2: unconfirmed] / [claim 3: verified] — since the device_class field itself states neither has been confirmed by a classification lookup.
This sets the build spec for every other slide on this deck: whether the symptom/medication questionnaire must be validated as part of one combined submission (Slide 3) or can be handled as separable accessory software, and therefore what the bench program (Slide 5) and the software/cybersecurity work (Slide 4) actually have to prove before a submission can be filed. It is also the condition the viability deck's capital-to-first-dollar slide names as the reason it cannot price a build timeline at all.
Naming it is not a recommendation, a gate, or a kill.