Patient-controlled health records AI
OpenKP
OpenKP is a local-first MCP server for Kaiser Permanente Northern California members who want an AI assistant to read, compare, and carefully act on their own patient-portal record. It is strongly aligned with patient agency, but remains a draft profile because it is technical to install, NorCal-only, not independently audited, dependent on fragile portal endpoints, and may conflict with Kaiser portal terms. Disclosure: OpenKP and HugoScore share the same maintainer, so this profile is self-evaluated and not an independent review.
Public-source research has been drafted; final human publication review and change-log detail are still required.
Summary judgment · 91% toward patient-directed
Strongly agency-expanding
OpenKP is designed for patients to direct AI over their own portal record using their own credentials, on their own machine, with local-first storage and explicit write confirmations.
Patient agency
How this tool changes agency
Workflows include longitudinal note review, lab drift questions, provider comparison, access-log inspection, refill preview/commit, and non-urgent care-team messaging.
Use is voluntary and local, but setup requires Git, Python, MCP configuration, a compatible client, and a KP NorCal account.
Patient-facing signals
Who does this AI serve?
The patient runs the server locally, uses their own credentials, chooses the assistant, and directs AI over their own portal record.
Can patients tell AI is involved?
OpenKP is explicitly an MCP bridge between an AI assistant and the patient's portal session.
Can patients meaningfully choose?
Use is voluntary and local, but setup requires Git, Python, MCP configuration, a compatible client, and a KP NorCal account.
Can patients correct or challenge what the AI produces?
Patients can inspect outputs and audit local write actions, but LLM reasoning errors and portal-source inaccuracies still require patient verification and ordinary Kaiser correction pathways.
Does it help patients understand or act?
Workflows include longitudinal note review, lab drift questions, provider comparison, access-log inspection, refill preview/commit, and non-urgent care-team messaging.
Text findings
Conflict of interest
Self-evaluated: OpenKP and HugoScore share the same maintainer
Hugo Campos maintains both OpenKP and HugoScore, so this profile is a self-evaluation rather than an independent review. It is published with that label, and independent third-party review of OpenKP is invited and outstanding.
Who is left out or burdened?
Technical and regional burden is substantial
OpenKP is only tested for KP NorCal and is aimed at technically curious users comfortable with cloning a repo, configuring MCP, and handling local credentials.
What happens to patient data?
Local-first, but the user's AI client sees returned record content
OpenKP has no hosted service and stores credentials/sessions locally, but parsed record content is returned to the user's chosen MCP client/assistant, which has its own data policies.
Are the clinical boundaries clear?
Clear in wording, high-stakes in use
Documentation says OpenKP is not a clinical tool and does not diagnose or recommend treatment, but it enables actions and interpretations around real portal data.
Who defined what good looks like?
Patient-maintainer-defined and source-auditable
The project is source-available with tests and explicit principles, but no independent security audit, usability study, or safety evaluation was found.
Review method
Deep public-source review of openkp.org, the public GitHub repository, README/design documentation, MCP server source, license metadata, Kaiser terms context, MCP documentation, and HIPAA right-of-access context; no hands-on install, security audit, or live Kaiser account testing.
Draft profile · Medium-high draft, source-available