Use case · Healthcare assistant

A clinical assistant that remembers the patient, not the transcript

Allergies, medication changes, and stated preferences, carried forward visit after visit. EU-hosted. Every read and write logged with a lawful-basis tag.

The idea

Want to build a clinical assistant that actually remembers each patient? Here is how

Think about a really good family doctor in a small town. You walk in and before you say a word she already knows you are allergic to penicillin, that you switched off the statin last spring because it gave you muscle pain, and that your mother had the same heart thing.

She does not flip through a thick folder while you sit there. She just knows, because she has carried your story forward visit after visit. The penicillin allergy from three years ago is as present in her head as the cough you came in with today. Nothing about you got lost between appointments.

That quiet carried memory is exactly what a chatbot does not have. Each visit, it starts from zero. It transcribes, it summarises, and then it forgets, so the next time the patient walks in the assistant has no idea what was said in April.

Korely is that carried memory. You ship the assistant, we carry the patient story forward.

How you build it

Eight steps, and the last one is the part you skip

  1. 01

    Pick your framework and model

    You probably already have Claude Code or Cursor to write the agent, and an LLM you trust for the clinical reasoning. That part you keep. We do not touch the model.

  2. 02

    Define the safety frame first

    Decide what the assistant is allowed to say, where it must defer to a clinician, and how it hands off. Memory does not replace judgement, it feeds it.

  3. 03

    Give every patient their own private space

    With Korely you set an end_user_id per patient, so one patient allergies, medications, and preferences never leak into another patient answers. Same key, fully isolated rooms.

  4. 04

    Write down what matters as the visit happens

    When the patient mentions a penicillin allergy, a medication change, or that they prefer telehealth over coming in, the agent calls korely.add() scoped to that patient. It saves the fact, not a transcript.

  5. 05

    Read it back at the start of the next visit

    Before the agent answers anything, it calls korely.search() for that patient and gets back what is true right now: current meds, known allergies, stated preferences, in under 50 milliseconds with no model on the read path.

  6. 06

    Let the timeline correct itself

    When the patient says they stopped a drug, the agent writes the new fact and our two-stage contradiction step retires the old one, keeping it on the record as superseded so nothing is silently erased.

  7. 07

    Wire up the regulated bits you would dread building

    EU data residency, an audit log of every read and write, and one call to erase everything about a patient when they ask. These come with the memory layer, not as a six-month side project.

  8. 08

    Here is where you stop building

    You do not stand up a bi-temporal, graph-backed retrieval system, tune a reranker, run contradiction resolution, and pass a data-residency review on your own. Korely is that whole memory infrastructure, ready, starting at 19 euro a month. You ship the assistant, we carry the memory.

The shape of it

One patient, two visits, the story carried in between

Visit 1, April

The visit gets written down

  • Patient states a penicillin allergy and a medication
  • Agent calls add() scoped to this patient

Korely memory

Bi-temporal store, EU-hosted

  • Typed facts in the patient isolated space
  • A stopped drug is marked superseded, kept on the timeline
  • Audit log on every read and write

Visit 2, three months later

The agent shows up informed

  • Calls search() before it answers
  • Gets current allergies and meds in under 50ms

The search returns what is true now, not the whole record, but the history stays walkable. Every operation lands in the audit log, and a single erase call wipes everything about that patient.

How Korely fits

The hard part nobody wants to build, already built

What Korely saves you is the part nobody actually wants to build: a bi-temporal, graph-backed agentic-memory layer that is safe to point at patient data. Building it yourself means a vector store plus a full-text index plus a reranker plus contradiction logic plus a typed entity graph plus an effective-from and effective-until timeline on every fact, then wrapping all of it in EU residency, audit logging, and a clean delete path.

That is months of specialist work and an ongoing maintenance tax, and in healthcare it is also the part a reviewer will scrutinise hardest. We already did it. The memory is Postgres-only, hosted in the EU, with no LLM sitting on the read path, so reads come back in under 50 milliseconds. Retrieval is hybrid: full-text and pgvector fused with reciprocal-rank fusion and a reranker on top, all in Postgres, so the few facts that matter surface ahead of three visits of small talk.

And it actually works. At an equal token budget a reader answers 76 percent of long-horizon recall questions correctly from Korely selected memory versus 42 percent from a same-size recent-history window, a 34 point gap, reproducible. In a clinical setting that gap is the difference between an assistant that remembers the allergy and one that buried it under three visits of small talk.

For regulated teams that require on-prem or air-gapped deployment, that is an enterprise engagement and we scope it case by case. Talk to us at info@korely.ai.

Show me the code

Two calls, one isolated patient space, one-call erase

healthcare_assistant.py python 
import os
from korely_memory import Korely

# EU-hosted memory API. Data stays in the EU.
korely = Korely(api_key=os.environ["KORELY_API_KEY"])

# One isolated memory space per patient (hash the patient ID first)
patient = hash_patient("PAT-2026-04812")

# ── April: the patient mentions an allergy and a medication ─────
korely.add(
    "Allergic to penicillin. On lisinopril 10mg for blood pressure. "
    "Prefers telehealth over coming in.",
    end_user_id=patient,
    metadata={"lawful_basis": "vital-interest"},
)

# ── Three months later: read back what is true NOW ─────────────
context = korely.search(
    "current allergies and medications",
    end_user_id=patient,
)
# context → "Penicillin allergy. lisinopril 10mg." in under 50ms,
# no model on the read path. Every add/search is in the audit log.

# ── Right to be forgotten: erase everything in one call ────────
korely.delete_all(end_user_id=patient)

The same memory is reachable from any agent: Claude Code, Cursor, LangGraph, n8n, or a plain HTTP client against the REST API. Scope each patient with a different end_user_id and their facts stay in their own room.

When the facts change

The assistant answers about the right drug, not the loudest one

A patient was put on lisinopril for blood pressure two years ago. Last spring it started giving her a dry cough that would not quit, so her doctor swapped her to losartan and the lisinopril was stopped. Today she opens the patient assistant and asks whether her current blood pressure medication is safe to take with the new cold remedy she just bought.

A plain chatbot, or a naive recent-history window, will happily reach back and answer about lisinopril, because that is the drug it saw mentioned the most across her record. Korely answers from what is true now. The agent reads her facts, sees that lisinopril is marked superseded with an effective-until date and losartan is the current medication, and reasons about losartan.

The old fact is not deleted, it sits in the audit trail with its dates, so a clinician can later see exactly when and why the switch happened. Time-aware memory is the whole reason the assistant talks about the right drug instead of the loudest one.

timeline.py python 
korely.add(
    "On lisinopril 10mg for blood pressure.",
    end_user_id=patient,
    metadata={"effective_from": "2024-03-01"},
)

# Last spring: dry cough, doctor switches the drug
korely.add(
    "Stopped lisinopril (dry cough). Now on losartan 50mg.",
    end_user_id=patient,
    metadata={"effective_from": "2026-04-10"},
)

korely.search("current blood pressure medication", end_user_id=patient)
# → "losartan 50mg" (current). lisinopril marked superseded.

# Full history stays walkable via the REST API:
# GET /v1/memories/{id}/history  -> timeline with effective dates

Frequently asked

Healthcare deployment, common questions

Is this safe to point at patient data, and where does it live? +

The memory lives in a managed store hosted in the EU, Postgres with vector and graph indexes, and nothing leaves that region. Every read and write is recorded in an audit log so you can show who or what touched a patient record and when. You do not host or harden any of it yourself. We are honest that Korely is the memory layer, not a certified medical device, so you keep your own clinical safety frame and human oversight on top of it.

How do you keep one patient's data from leaking into another patient's answers? +

Every patient gets their own end_user_id, which scopes their memory to a fully isolated space under your one API key. A search for patient A only ever returns patient A facts. There is no shared pool the model can accidentally reach across, so allergies, medications, and preferences stay where they belong.

A patient asks us to delete everything. How hard is that? +

It is one call. You delete by that patient end_user_id and every memory, every fact, and the full timeline for that patient is erased from the store. It is built for the right-to-be-forgotten case from day one, not bolted on later, which is exactly what a data-protection review will ask you about.

How does it handle a medication or diagnosis that changes over time? +

Facts are time-aware. When a patient stops a drug or a preference changes, the agent writes the new fact and our two-stage contradiction step retires the old one, keeping it on the record as superseded with its effective dates instead of silently overwriting it. So the assistant answers from what is true now, and a clinician can still retrace the history. In our equal-budget test, selected memory answered 76 percent of long-horizon recall questions correctly versus 42 percent for a same-size recent-history window.

Will adding memory slow the assistant down in front of a patient? +

No. There is no language model sitting on the read path, so a recall comes back in under 50 milliseconds. The agent reads the patient current allergies and medications before it answers, and the patient does not feel a pause.

Do I have to rebuild my agent to use this? +

No. You keep the framework and the model you already have, whether that is Claude Code, Cursor, LangGraph, or a plain HTTP client. You add two calls, korely.add() when something worth remembering happens and korely.search() before the agent answers. The memory infrastructure is the only part you are handing over, and it starts at 19 euro a month with a free tier to try it.

Wire memory into one patient flow today

The free tier lets you build memory into one patient flow today, and pricing starts at 19 euro a month when you outgrow it. Need on-prem or air-gapped deployment, a signed DPA, or a retention agreement? That is an enterprise engagement, write to info@korely.ai and we will scope it.

See pricing and start free Talk to us about on-prem

Looking for a different shape? See the other nine use cases →