Retrieval for policies and patient context

When a coordinator asks, “Can I move this appointment to tomorrow?”, the answer may depend on a clinic policy, current availability and the patient's selected appointment. Those facts have different owners and lifetimes. Putting all of them in one vector index makes that distinction easy to lose.

Our assistant has context and optional memory integration. In the inspected execution path, passing history into a function does not guarantee that the base agent uses it. This chapter develops a reference retrieval design around the information an administrative workflow actually needs.

Route the information request before retrieval

I would separate policy questions, record lookups and workflow state. Policy text belongs in a versioned knowledge store. The selected appointment belongs in the scheduling service. The pending approval belongs in the proposal store.

This split lets the system explain why it knows something. An embedding similarity score should never become evidence that a slot is still free.

Index the policy's identity, not just its words

A useful policy chunk needs enough metadata to establish where and when it applies:

{
  "document_id": "scheduling-policy",
  "version": 3,
  "chunk_id": "reschedule-window",
  "tenant": "clinic-a",
  "location_scope": ["location-001"],
  "roles": ["scheduler"],
  "intent": "reschedule",
  "status": "approved",
  "valid_from": "2026-09-01T00:00:00Z",
  "valid_to": "2027-01-01T00:00:00Z",
  "source_anchor": "section-4.2"
}

These are synthetic reference fields. I would chunk around a complete rule, its exceptions and relevant definitions. Splitting “except for...” into another chunk can reverse the operational meaning of a passage. Tables may need a normalized representation that preserves headers and row relationships.

The ingestion pipeline should record the original document hash, parser version, approval status and effective date. Publishing a new document should not immediately make it authoritative if it is still awaiting approval. Retired versions can remain available for audits without being eligible for current answers.

Filter before ranking and before generation

The offline lab uses a deliberately small filter to demonstrate the boundary:

eligible = [
    r for r in records
    if r["tenant"] == tenant
    and r["intent"] == intent
    and set(r["roles"]) & set(allowed_roles)
    and r["valid_from"] <= now < r["valid_to"]
    and r["status"] == "approved"
]

A production retrieval engine should apply equivalent authorization constraints before selecting candidates, then enforce them again when loading the final content. Post-filtering a global top-five result can both leak metadata and starve the answer of relevant authorized passages. Caches need the same scope dimensions.

For policy search, I would start with keyword and semantic candidates, merge and rerank them, then retain a small evidence set. Exact policy codes and clinic names benefit from lexical matching; paraphrased staff questions benefit from semantic retrieval. The weights and candidate counts should be selected from a labeled policy-query set, not copied from another RAG project.

Return evidence that can be checked

The response contract should keep the answer and citations separate:

{
  "answer": "This request needs a coordinator review before rescheduling.",
  "evidence": [{
    "document_id": "scheduling-policy",
    "version": 3,
    "chunk_id": "reschedule-window",
    "source_anchor": "section-4.2"
  }],
  "next_action": "prepare_review_task"
}

The answer text here is illustrative; no actual clinic policy is implied. The UI should resolve the citation through an authorized document route. A generated URL should not bypass access checks or point to an uncontrolled external destination.

For conflicting current policies, I would show the conflict and route it to the policy owner. Asking the model to choose the more plausible rule hides a governance problem inside generation. Missing evidence should produce a narrow abstention or a staff task, not a confident policy invention.

Keep patient context task-specific

For rescheduling, the assistant may need the appointment ID, location, type and relevant contact preference. It usually does not need unrelated clinical notes. I would resolve the necessary fields through a typed service query after authorization, then keep those fields in a short-lived context envelope.

Long-term conversational memory should not be the only source of a changed telephone number, consent preference or appointment status. Those updates belong in the appropriate system of record. If a user says “Use my new number,” the assistant should enter a contact-verification workflow rather than store a free-text memory and begin sending there.

Evaluate retrieval separately from answer quality

My first evaluation set would contain the correct policy chunk IDs and versions for each question. I would measure whether the current authorized evidence appears in the candidate set, whether reranking keeps it and whether the answer's claims are supported by it.

Then I would add stale policies, another tenant's near-identical document, a policy with an exception in a table and a hostile instruction embedded in an otherwise relevant passage. The expected result is not always an answer; some cases should abstain or escalate.

The implementation kit includes an authorization/effective-date filter test and a proposed benchmark specification. It does not include a trained retriever or measured retrieval scores. That separation gives the developer a clear sequence: establish the evidence contract, build the index, label the questions and then compare retrieval strategies.