idea-011 · desirability 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: the user. Two of them, really: the CKD/heart-failure outpatient wearing the patch between clinic visits, and the prescribing clinician who has to act on what it says.
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 the condition at all. This is the first deck built for this candidate — there is no prior build to compare against. See docs/deck-spec.md.
Would have to be true: There would have to be a large population of adult outpatients with CKD or heart failure, undergoing RAASi initiation or up-titration, who are currently sent back for a repeat venous potassium draw between scheduled visits — a burden real enough that a between-visit screening step is worth wearing continuously.
Where it stands: The comorbidity population is plausible but every population figure in this file is unconfirmed: HF/CKD comorbidity reported at 20-67% with no resolvable source [claim 8: unconfirmed], a US GWTG-HF registry finding 64% of HF hospitalizations had discharge eGFR <60 [claim 27: unconfirmed], and a US Medicare FFS cohort of 621,171 HFpEF patients with rising MRA initiation [claim 29: unconfirmed]. None of these establish the actual moment this device targets — the between-visit draw itself. Whether outpatient RAASi titration in fact requires repeat venous draws between scheduled visits, and what that currently costs a patient in time and travel, has no source in the file at all until this deck's own write-back [claim 31: unverified].
What would settle it: Chart review or clinic-workflow interviews establishing the actual between-visit draw frequency and how patients currently obtain it (return to clinic, outside lab, home phlebotomy).
If it's false: If titration monitoring rarely requires an out-of-clinic draw — if it is folded into a visit that would happen anyway — the premise that this device removes a real burden collapses, and Mechanism & clinical risk and TAM both rest on a moment that doesn't occur as described.
Would have to be true: A patient would have to wear a continuous adhesive multi-lead ECG patch between visits, and the prescribing clinician would have to receive an ECG-based hyperkalemia flag and act on it before a lab value confirms anything — ordering a confirmatory draw promptly rather than waiting for the next scheduled one.
Where it stands: This is the candidate's own named assumption, and the file is unusually direct about its status: "clinicians managing RAASi titration would be willing to act on an ECG-based hyperkalemia flag without an accompanying lab value, and would order a confirmatory draw promptly when flagged" was run through the adoption connector and returned unverifiable — "needs primary research... stays unconfirmed permanently unless a human attaches real research" [claim 12: unconfirmed]. The nearest real-world proxy is what clinicians do when a lab potassium value comes back high, not an ECG flag: in a US HFrEF registry, RAAS-inhibitor discontinuation ran 12.7%-20.4% by drug class over 18 months, with CKD the only independent predictor of increased discontinuation risk [claim 20: unconfirmed]. That is action on a confirmed lab number, the opposite of the behaviour this device asks for.
What would settle it: Nothing a connector in this repo can reach — the file says so explicitly. A prospective study or structured clinician interviews specifically asking about action on an ECG-only flag, not a lab value.
If it's false: The device generates alerts nobody acts on differently than they already do, and the entire clinical-workflow premise (screen → confirmatory draw → decision) never triggers the confirmatory draw promptly enough to matter.
Would have to be true: Beyond the prescriber and patient, a payer or the patient's own wallet would have to cover the device (see the viability deck's Slide 1 for who and from what budget), and — for the patient side specifically — a caregiver or the patient would have to manage a continuous adhesive patch and paired reader without clinical staff supervision.
Where it stands: The payer question is CMS's own, still-proposed RAPID pathway [claim 4: verified], [claim 5: verified], [claim 6: verified], [claim 7: verified] — verified as to what the notice says, not verified as to whether this device qualifies or whether the notice is ever finalized (comment period closed 2026-10-13). No HCPCS code, payment rate, or coverage policy specific to this service has been identified [claim 11: unconfirmed]. Whether a patient or caregiver can correctly apply, wear, and maintain the patch unsupervised for multi-day stretches is this deck's own write-back [claim 33: unverified] — nothing in the file addressed it before this pass.
What would settle it: A usability study with real patients/caregivers on device application and multi-day wear; the reimbursement questions are the viability deck's to settle.
If it's false: Either the money doesn't reach the device (viability's problem) or the device sits unworn in a drawer after week one (a desirability problem no reimbursement fix solves).
Would have to be true: The burden of continuous wear, plus the rate of unnecessary confirmatory draws triggered by false alarms, would have to be smaller than the burden the device replaces.
Where it stands: The algorithm's own reported performance sets a real cost here. At the 90%-sensitivity operating point the Mayo model's specificity across three validation sites was only 54.7%-63.2% [claim 17: unconfirmed] — meaning a majority of flagged patients without true hyperkalemia would still need, and get, a confirmatory draw under this candidate's own intended-use framing. That is not a hypothetical cost; it is the shape of a false-alarm rate a patient would experience directly, sourced to the same study that is this device's strongest mechanism evidence. Out-of-pocket cost while no reimbursement pathway is finalized is the viability deck's Slide 1-2 question, referenced rather than restated here [claim 11: unconfirmed].
What would settle it: The false-alarm burden, translated from the Mayo cohort's specificity into an expected confirmatory-draw rate for this device's intended population — an extrapolation this file has not attempted and that a full-text read of PMID 30942845 could narrow.
If it's false: The device trades one burden (a scheduled venous draw) for a worse one (frequent unscheduled draws triggered by false alarms), and the desirability case inverts.
Would have to be true: A prescriber would have to be able to point to a guideline mention, a colleague's experience, or a visible reduction in hyperkalemia-related complications before recommending this to a patient.
Where it stands: No claim in the file speaks to guideline recognition — this deck's own write-back records that no clinical practice guideline (KDIGO, ACC/AHA/HFSA) currently mentions ECG-based hyperkalemia screening as an adjunct to RAASi monitoring [claim 32: unverified]. The mechanism evidence a prescriber could cite instead is thin by design: single-institution, retrospective, abstract-only, with the file's own Verifier noting "not refuted... but not a precise match either" and full-text methodology still unread [claim 3: unconfirmed], [claim 17: unconfirmed].
What would settle it: A guideline search (KDIGO, ACC/AHA/HFSA) specifically for mention of non-invasive hyperkalemia screening; a full-text read of PMID 30942845 for methodology and any external validation.
If it's false: Prescribers have nothing to cite when a patient or a formulary committee asks why this device rather than the status quo, and adoption stalls on that gap regardless of what the underlying accuracy turns out to be.
Would have to be true: In the first handful of real users, the confirmatory-draw rate triggered by device flags, and the time between a flag and a clinician acting on it, would have to be observably close to what claim 12 and claim 20 leave open.
Where it stands: The file has already run the cheapest available check on the central adoption question and it came back structurally unanswerable by any connector here [claim 12: unconfirmed]. The next-cheapest observation is not a connector call at all: a small number of real users generating real flags, with a clinician's actual time-to-confirmatory-draw recorded against the claim-20 lab-value baseline [claim 20: unconfirmed].
What would settle it: A small pilot cohort, instrumented for flag-to-draw time and false-alarm rate — the first primary research this candidate's desirability case has ever had.
If it's false: The pilot itself is the falsifier; there is no cheaper substitute.
Every condition above with nothing verified behind it. This candidate has four verified claims total, and all four concern the same thing — what CMS's proposed RAPID notice says, not whether this device qualifies for it or whether anyone wants it [claim 4: verified], [claim 5: verified], [claim 6: verified], [claim 7: verified]. Nothing verified in this file speaks to desirability at all.
unverifiable; the load-bearing condition.
If only one thing from this chair could be checked: whether a prescriber managing RAASi titration would act on an ECG-based hyperkalemia flag — ordering a confirmatory draw promptly — without an accompanying lab value [claim 12: unconfirmed].
The candidate's own Generator flagged this as an assumption rather than a fact, ran it through the one connector built to check adoption claims, and got back a structural answer: this stays unconfirmed permanently unless a human attaches real research. Every other desirability condition on this deck — the burden this device targets, the false-alarm cost, the guideline gap — describes context around this question. None of them resolves it, and nothing in this repo's tooling ever will.
Naming it is not a recommendation, a gate, or a kill. It is the answer to "check what first."