idea-011 · 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 have to turn a single-institution retrospective algorithm into a continuously worn patch, get it through a regulatory pathway that may not exist yet, and produce evidence a reviewer will ask for.
How to read this: every slide is a condition, not a conclusion. A bracketed claim reference points into knowledge-base/candidates/idea-011.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. This is the first deck built for this candidate. See docs/deck-spec.md.
Would have to be true: An adhesive patch would have to continuously record ECG waveform data between clinic visits, score it on-device or in the cloud for hyperkalemia-risk pattern (e.g. T-wave morphology), and push an alert prompting a confirmatory lab or point-of-care potassium draw — never a stand-alone diagnostic claim.
Where it stands: This is the candidate's own deliberate design choice, stated in frontmatter rather than as a checkable claim: a screening-trigger framing, chosen specifically to avoid a stand-alone diagnostic-replacement claim's harder evidence bar — [no claim] backs the framing itself. No sensitivity, specificity, or alert-latency target is specified anywhere in the file as a build requirement — [no claim]. The nearest performance figures are Mayo Clinic's own retrospective results: AUC 0.853-0.883 across three validation sites, specificity 54.7%-63.2% at a 90%-sensitivity operating point [claim 17: unconfirmed] — a result, not a spec.
What would settle it: A clinician-defined target operating point (sensitivity/specificity trade-off) for this intended use, which no source in this file has set; whether FDA would accept "screening adjunct" as materially lower-burden than a stand-alone diagnostic claim is explicitly unconfirmed and named in the file as exactly the kind of question Factor 1 verification should resolve.
If it's false: Without an agreed target operating point, the mechanism slide below has nothing to be measured against.
Would have to be true: ECG-morphology changes (e.g. T-wave features) would have to discriminate hyperkalemia risk at a clinically useful accuracy — and that accuracy would have to be established at more than abstract depth.
Where it stands: The best evidence on record is a single Mayo Clinic-affiliated deep-learning model, trained on 1,576,581 ECGs from 449,380 patients and validated retrospectively on 61,965 stage ≥3 CKD patients across three Mayo sites, reporting 2-lead AUCs of 0.883 (Minnesota), 0.860 (Florida), 0.853 (Arizona) [claim 17: unconfirmed] — figures the Verifier confirmed match the source abstract exactly, correcting an earlier claim's imprecise "approximately 0.88-0.89" range [claim 3: unconfirmed]. The base rate the model was validated against was itself low: hyperkalemia prevalence 2.6%-4.8% in those same cohorts [claim 18: unconfirmed] — a low-prevalence target is a harder one for any screening test to hold specificity against. Both claims stay unconfirmed, and the file is explicit about why: a literature-detail read returns a structured abstract, "a lead to read, not evidence for a claim," so full-text methodology and any external (non-Mayo) validation remain unread.
What would settle it: A full-text read of PMID 30942845 for methodology, any 4-lead result, and external validation; a search for any prospective or non-Mayo multi-site validation published since 2019 — none has been located by any pass on this file so far.
If it's false: If the mechanism does not discriminate risk usefully outside a single health system's retrospective data, nothing downstream — the build spec, the bench plan, the regulatory pathway — has a working device to attach to.
Would have to be true: Whichever regulatory route applies would have to define a concrete evidence and standards package — and the candidate's own frontmatter carries two live, unresolved routes rather than one.
Where it stands: A 510(k) route is contingent on a cleared predicate existing, and none has been found: no clearance or De Novo grant for KardiaK, the closest analog, has been located [claim 2: unconfirmed]. A broadened, non-top-1-match openFDA search confirms this more specifically — zero devices under any name carry a hyperkalemia, electrolyte, or potassium indication, and all ten product codes in the one classification family built for ECG-based AI "notification software" cover unrelated cardiac conditions [claim 25: unconfirmed] (mixed finding). That narrows the practical build target to De Novo, with no existing predicate-code family to shorten the special-controls package — a harder, more specific engineering target than "510(k) or De Novo" in the abstract. A separately verified but tangential finding is that this product family's own regulation_number field does not correspond to a codified CFR section [claim 26: verified] — a registry-metadata quirk, not a build requirement.
What would settle it: FDA pre-submission (Q-Sub) engagement once a De Novo path is committed to, to define the special-controls performance battery this device would need to meet — a route with no shortcut available given claim 25's finding.
If it's false: If a 510(k) predicate surfaces later, the build package shrinks substantially; if it doesn't, the special-controls package has to be built from nothing, which is the more expensive and slower of the file's own two named routes.
Would have to be true: The hyperkalemia-detection accuracy demonstrated on Mayo Clinic's retrospective, single-institution, clinical-grade 2-lead ECG captures would have to transfer to a continuously worn adhesive patch's signal — despite motion artifact, multi-day electrode contact degradation, and a lead placement that may differ from a bedside capture.
Where it stands: No claim in the file addresses this transfer question at all — the source evidence [claim 17: unconfirmed] is entirely short, clinical-grade, single-timepoint ECG captures, not continuous ambulatory wear. This deck's own write-back names the gap directly: whether the demonstrated AUC and specificity survive the move to a continuously-worn patch's signal quality is unestablished anywhere in this file [claim 37: unverified].
What would settle it: A bench comparison of algorithm performance on wearable-patch ECG signal (with realistic motion artifact and multi-day wear degradation) against the same algorithm's performance on Mayo's original clinical-grade captures.
If it's false: The device's core mechanism claim degrades exactly where it matters most — in the unsupervised, multi-day, ambulatory setting this candidate is designed for — and no amount of regulatory or reimbursement progress compensates for that.
Would have to be true: A bench or retrospective validation would have to show the model holds its discrimination accuracy on continuously streamed wearable-patch waveform data — before any patient wears the device.
Where it stands: No such validation exists in the file — this deck's write-back records the gap as a standalone condition [claim 38: unverified], directly downstream of Slide 4's transfer question. The device would also have to survive multi-day continuous wear physically (battery, skin adhesion, wireless streaming) in an unsupervised home setting, which is likewise unaddressed by any existing claim [claim 39: unverified].
What would settle it: The bench validation named above, run against a target operating point that Slide 1 notes does not currently exist either; a multi-day wear-reliability bench test.
If it's false: The mechanism and the hardware both fail before an animal or patient is ever involved — which is the cheapest possible place for this candidate to fail, and this file currently has zero evidence ruling either failure out.
Would have to be true: The patch, reader, and streaming pipeline would have to be manufacturable at scale, correctly applied by an untrained patient or caregiver, and reliably operate for days at a time in a home rather than a clinic.
Where it stands: No claim addresses manufacturing, supply chain, or the home-use reality — [no claim] on all three. The multi-day wear-reliability condition named on Slide 5 [claim 39: unverified] and the patient/caregiver application question named on the desirability deck [claim 33: unverified] both bear directly here; this slide references rather than restates them, per the deck-spec's guidance on shared conditions.
What would settle it: A contract-manufacturing quote against a defined device spec (which Slide 1 notes does not yet exist); a usability study with real patients and caregivers, not technicians.
If it's false: A device that performs on the bench but cannot be reliably worn or applied by its actual intended user never generates the flag it was built to generate.
Would have to be true: The device's design — patch form factor, lead configuration, and algorithm — would have to be buildable around whatever AliveCor (or any other holder) has patented in ECG-morphology-based potassium inference.
Where it stands: Genuinely open. AliveCor holds Breakthrough Device Designation on the closest competing mechanism and may hold patent claims on ECG-morphology-based potassium inference, but the claim naming this was found truncated in the file, no specific patent number was ever identified, and no lookup could be run — the patent connector requires a specific patent ID, and this environment's PATENTSVIEW_API_KEY is not configured [claim 13: unverified].
What would settle it: A configured API key and a real assignee search for AliveCor and adjacent ECG-hyperkalemia patent families, down to specific patent numbers and their claim scope.
If it's false: Automatic kill under the Stage 5 gate, regardless of every other score — the one condition on this deck with that property.
Every condition above with nothing verified behind it. This candidate carries one verified claim relevant to this lens [claim 26: verified], and it is tangential — a registry-metadata discrepancy in an unrelated product-code family, not a fact about this device's own mechanism, build spec, or pathway.
If only one thing from this chair could be checked: whether the hyperkalemia-detection accuracy demonstrated on Mayo Clinic's retrospective, clinical-grade ECG captures survives the move to a continuously worn adhesive patch's signal [claim 37: unverified].
Every other feasibility question on this deck assumes the mechanism holds outside the exact conditions it was measured in. The regulatory build spec (Slide 3), the bench-evidence plan (Slide 5), and the manufacturing question (Slide 6) are all downstream of an algorithm that works on this device's actual signal — not the short, clinical-grade captures the only available evidence [claim 17: unconfirmed] was built and validated on. This is also the cheapest of this deck's open questions to test: a bench comparison, not an animal study or a regulatory submission, and it is the one result that would tell engineering whether anything else here is worth funding.
Naming it is not a recommendation, a gate, or a kill.