FRAME Audit: OpenKP

URL: https://github.com/hugooc/OpenKP
Date: 2026-05-28
Analyst: FRAME v1.0 / Synambix
Documents reviewed: README.md, DESIGN.md (referenced)

One-Line Verdict

FOUNDATIONAL | Score: 21/24 | The sharpest scope definition and strongest CLAIM framing in the batch — patient-directed MCP on patient-owned data, surfacing what Kaiser’s own portal structurally cannot show.

Dimension Scores

Dimension	Score	Evidence
Patient Agency Index	3/3	Local-only by design; patient uses their own KP credentials; every write requires confirm=True; core use case is surfacing how the patient shows up in the institutional chart — not just consuming institutional data output
Architecture Integrity	3/3	No OpenKP server, no shared database, no remote credential store; credentials in OS keychain, never logged or uploaded; writes require confirmation; PHI never leaves machine except direct KP requests by patient
Technical Maturity	3/3	CI badge passing; 567 tests on macOS; per-tool status documented (live-verified / preview-only / deferred); Windows support documented with specific caveats; Phase 2 closed, Phase 3 active
Safety & Disclaimer Posture	2/3	Writes require confirm=True documented; “not a packaged consumer product” stated; KP-NC scope clearly bounded; technical audience assumption explicit. No “not a medical device” disclaimer found. No emergency services mention.
Interoperability Stack	2/3	19 read + 2 write tools: appointments, labs, messages, medications, problems, allergies, demographics, visit notes, AVS, care team, implanted devices. KP-specific portal only — not FHIR, no HL7, no CCDA. Limited scope by design.
CLAIM Alignment	3/3	”Critical AI health literacy in practice” stated explicitly in README. References NAM Perspectives article by name. References aipatients.org. Core example question surfaces how patient engagement is documented in the chart — makes institutional characterization visible.
Sustainability Model	2/3	PolyForm Noncommercial 1.0.0; single maintainer (hugooc = Hugo Campos); 6 stars, 1 fork; no community channel. ADR document structure and design docs suggest long-term architectural thinking.
Scope Honesty	3/3	KP-NC only stated explicitly; “other regions will hit breakage” documented; install path has explicit prerequisites; per-tool status column; Phase tracking; Windows caveats itemized
TOTAL	21/24

Key Strengths

The core use case is the CLAIM argument made executable. “Read every visit note from the last two years. Find every instance where I raised a concern, asked a question, or pushed back. How was it documented?” This is not a data retrieval question. It is a power-structure interrogation. OpenKP makes the invisible visible: not what the institution recorded about you, but how the institution characterized your engagement. No other project in this batch has this as its opening example.
Local-first is absolute, not aspirational. No server. No database. No credential store. No middle layer. The architecture is the privacy guarantee, not a policy.
Per-tool status discipline. Live-verified / preview-only / deferred — with specific test counts and platform caveats. This is the most honest technical status reporting in the batch.
PolyForm Noncommercial for personal use, commercial path preserved. Same license choice as OwnChart — emerging standard for patient AI tools that want to stay open for patients while protecting against commercial extraction.

Key Gaps

KP Northern California only. This is documented honestly, but it limits impact to one of the largest but still regional patient populations. The path to other regions (SoCal, Northwest, Hawaii) is documented as needing HAR captures and issues from those users — not yet designed in.
No explicit medical device disclaimer. The README states “not a packaged consumer product” and documents the technical prerequisites carefully, but does not include the standard “not a medical device, not intended to diagnose or treat” language that the other FOUNDATIONAL projects carry.
Write capabilities are in progress (Phase 3). The confirmation gate design is documented, but write tooling is not yet live-verified. The safety of write operations is documented at the design level, not yet confirmed at the test level.
Single maintainer with no community intake path. Hugo Campos is a known and respected figure in the patient AI space, but there is no Contributing guide, no Discussion board, no mechanism for KP members in other regions to formally contribute.

CLAIM Assessment

Contextual Grounding: Exemplary in scope. Every query is grounded in the patient’s actual Kaiser records, retrieved in real time from the patient’s own authenticated session. The system cannot produce generic health information — it can only return what is actually in this patient’s chart. The boundary is hard.

Interrogative Stance: Strongest in batch. The opening example question is designed to surface the gap between what the patient experienced and how the institution documented it. “Kaiser’s portal shows you plans, orders, and results. It doesn’t show you how you show up in the chart. OpenKP can.” This is interrogative stance as product design, not as principle.

Associative Integration: Moderate. OpenKP produces structured output via Claude Desktop, which the patient can work with in conversation. But there is no documented path for connecting OpenKP outputs to other health data sources, creating longitudinal records, or building a research workspace. Single-source by design.

Judgment Layer Activation: Strong. Confirm=True on every write. Patient initiates every query. The system is request-response, not agent-autonomous. Nothing happens without the patient choosing it.

Methodological Transfer: Present in concept. The NAM Perspectives reference and aipatients.org citation point toward a broader literacy framework. The tool teaches patients what questions to ask about institutional documentation. But the README does not include educational scaffolding — it assumes the patient already knows what to interrogate.

Patient Agency Verdict

OpenKP is the most direct implementation of the CLAIM framework’s core claim: that AI can help patients see what institutional systems are structurally not built to make visible. The core use case — “how was my engagement characterized?” — is a patient agency move that no portal, EHR, or clinical workflow is designed to support. OpenKP builds it in 24 MCP tools and 567 tests.

The limitation is scope: KP Northern California, technically confident users, Claude Desktop required. This is a tool for a specific, capable patient population at a specific institution. It is not yet a model deployable at scale or across systems. But as a proof of concept for what patient-directed institutional audit looks like, it is the most precise implementation in this batch.

Evidence Flags

None. Every capability claim is documented with tool counts, test numbers, Phase tracking, and platform-specific caveats. The scope limitation is stated prominently rather than buried.

Recommendation

CITE + TRACK. OpenKP is the cleanest executable demonstration of Critical AI Health Literacy principles available in open source. The opening example question belongs in CLAIM framework presentations and #PatientsUseAI communications. Track Phase 3 (writes) completion and regional expansion progress.